11
IEEE TRANSACTIONS ON INTELLIGENT VEHICLES, VOL. 5, NO. 4, DECEMBER 2020 545 An Attribute-Isolated Secure Communication Architecture for Intelligent Connected Vehicles Mu Han , Member, IEEE, Ailan Wan, Fengwei Zhang , and Shidian Ma Abstract—The rapidly increasing connectedness of modern ve- hicles leads to new security challenges for intelligent connected vehicles (ICVs), where some potential attackers can achieve unau- thorized access to gain control of the vehicle by injecting mali- cious information into in-vehicle electronic control units (ECUs). Therefore, in this paper, a secure attribute-isolated communication architecture for an ICV, which introduces attributes into the ECUs to achieve authorized access among the ECU nodes is proposed. First, an analysis of the functional attributes of all of the in-vehicle ECUs in an intelligent connected environment and a division of the functional attributes of the ECUs into five classifications are per- formed. Second, based on the above-classified attributes, a secure attribute-isolated communication architecture is demonstrated. The ECUs have different access rights, allowing only the ECUs with the same functional attributes in the internal network of the vehicle to communicate. Then, it is proven that the proposed architecture can resist forgery and eavesdropping attacks under the random oracle model. Finally, the secure attribute-isolated communication architecture is constructed in a hardware environment and evalu- ated with an in-vehicle network simulator (IVNS). The evaluation results show that the average memory usage with 120 ECUs and 100 messages is below 40 MB and the bus load can be reduced to 18.96% using the proposed security architecture compared to the bus load of existing architectures. Therefore, the proposed secure attribute-isolated communication architecture solves the problem of the tradeoff between the security threat of unauthorized access and the high bus load of existing in-vehicle architectures. Index Terms—ICV, in-vehicle network, security, attribute- isolated architecture, ECU functional attributes. Manuscript received October 16, 2018; revised January 16, 2019, June 21, 2019, and January 30, 2020; accepted September 14, 2020. Date of publication September 29, 2020; date of current version November 23, 2020. This work was supported in part by the Six Talent Peaks Project of Jiangsu Province (DZXX-012), in part by Natural Science Fund for Colleges and Universities in Jiangsu Province (12KJD580002), in part by Jiangsu Graduate Innovation Fund (KYLX_1057), and in part by Key Research and Development Plan of Jiangsu province in 2017 (Industry Foresight and Generic Key Technology) (BE2017035). (Corresponding author: Mu Han.) Mu Han is with the School of Computer Science and Communication En- gineering, Jiangsu University, Zhenjiang 212013, China, and also with the COMPASS Lab, Wayne State University, Detroit, MI 48202 USA (e-mail: [email protected]). Ailan Wan is with the School of Computer Science and Communi- cation Engineering, Jiangsu University, Zhenjiang 212013, China (e-mail: [email protected]). Fengwei Zhang was with the COMPASS Lab, Department of Computer Science, Wayne State University, Detroit, MI 48282 USA and is now with the De- partment of Computer Science and Engineering, Southern University of Science and Technology, Shenzhen 518000, China (e-mail: [email protected]). Shidian Ma is with the Automotive Engineering Research Institute, Jiangsu University, Zhenjiang 212013, China (e-mail: [email protected]). Color versions of one or more of the figures in this article are available online at https://ieeexplore.ieee.org. Digital Object Identifier 10.1109/TIV.2020.3027717 I. INTRODUCTION R ECENTLY, the rapid convergence of vehicles and infor- mation technology has resulted in a rapid increase in modern vehicles connected to the Internet [1]. Such a connection can make vehicles become rich sources of data, including both personal and vehicular information. However, it also means that vehicles inevitably become lucrative targets for hackers. In 2013, it was reported that a mass production hybrid vehicle had been cracked by hackers [2], who illegally manipulated the brake system through the on-board diagnostics (OBD) interface, allowing the hackers to cause traffic accidents and threaten the lives of the occupants. In 2015, the details of security attacks on a SUV have been unveiled [3]. The attackers were able to remotely invade the electronic control units (ECUs) through in-vehicle entertainment systems, and achieve remote control of the vehicle’s speed, air conditioning and windshield wipers. Subsequently, in 2017, other researchers hacked some other cars. They showed that they could remotely control the vehi- cle including critical vehicle controls. They showed that they could remotely control the vehicle including critical vehicle controls [4]. The security loopholes mentioned above originated from the limitations of the traditional in-vehicle network architecture: 1) The traditional in-vehicle network architecture is a closed environment, that is insufficiently adapted to the open envi- ronment of modern intelligent connected vehicles (ICVs) [5]. Any devices connected to the vehicle can obtain access to the in-vehicle information via Wi-Fi, Bluetooth or OBD interfaces. This increase in interconnections expands the attack surface of the vehicle [6], [7]; 2) The communication framework of the in-vehicle network has broadcast characteristics, in which the ECUs (nodes) exchange information in the form of plaintext [8]. Each ECU can communicate with other ECUs without requiring source or destination addresses. Hence, an attacker who infil- trates an ECU can easily impersonate any other ECU and finally achieve remote control of the vehicle. In this paper, an ECU access control mechanism for an ICV is designed, which achieves attribute-isolated communication among all of the ECUs. The ECUs’ access control mechanism solves the security threat of unauthorized access. Additionally, it reduces the high bus load of existing in-vehicle architectures. The main contributions of this paper are as follows: 1) An analysis of the functional attributes of in-vehicle ECUs is performed. According to the impact of the passenger’s func- tional requirements and the traffic environment on vehicles un- der intelligent connected environment, we divide the functional 2379-8858 © 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See https://www.ieee.org/publications/rights/index.html for more information. Authorized licensed use limited to: Southern University of Science and Technology. Downloaded on November 27,2020 at 07:31:27 UTC from IEEE Xplore. Restrictions apply.

An Attribute-Isolated Secure Communication Architecture ... · With the rapid development of artificial intelligence, inter-net technology, communication technology and computer

  • Upload
    others

  • View
    5

  • Download
    0

Embed Size (px)

Citation preview

  • IEEE TRANSACTIONS ON INTELLIGENT VEHICLES, VOL. 5, NO. 4, DECEMBER 2020 545

    An Attribute-Isolated Secure CommunicationArchitecture for Intelligent Connected Vehicles

    Mu Han , Member, IEEE, Ailan Wan, Fengwei Zhang , and Shidian Ma

    Abstract—The rapidly increasing connectedness of modern ve-hicles leads to new security challenges for intelligent connectedvehicles (ICVs), where some potential attackers can achieve unau-thorized access to gain control of the vehicle by injecting mali-cious information into in-vehicle electronic control units (ECUs).Therefore, in this paper, a secure attribute-isolated communicationarchitecture for an ICV, which introduces attributes into the ECUsto achieve authorized access among the ECU nodes is proposed.First, an analysis of the functional attributes of all of the in-vehicleECUs in an intelligent connected environment and a division of thefunctional attributes of the ECUs into five classifications are per-formed. Second, based on the above-classified attributes, a secureattribute-isolated communication architecture is demonstrated.The ECUs have different access rights, allowing only the ECUs withthe same functional attributes in the internal network of the vehicleto communicate. Then, it is proven that the proposed architecturecan resist forgery and eavesdropping attacks under the randomoracle model. Finally, the secure attribute-isolated communicationarchitecture is constructed in a hardware environment and evalu-ated with an in-vehicle network simulator (IVNS). The evaluationresults show that the average memory usage with 120 ECUs and100 messages is below 40 MB and the bus load can be reduced to18.96% using the proposed security architecture compared to thebus load of existing architectures. Therefore, the proposed secureattribute-isolated communication architecture solves the problemof the tradeoff between the security threat of unauthorized accessand the high bus load of existing in-vehicle architectures.

    Index Terms—ICV, in-vehicle network, security, attribute-isolated architecture, ECU functional attributes.

    Manuscript received October 16, 2018; revised January 16, 2019, June 21,2019, and January 30, 2020; accepted September 14, 2020. Date of publicationSeptember 29, 2020; date of current version November 23, 2020. This workwas supported in part by the Six Talent Peaks Project of Jiangsu Province(DZXX-012), in part by Natural Science Fund for Colleges and Universitiesin Jiangsu Province (12KJD580002), in part by Jiangsu Graduate InnovationFund (KYLX_1057), and in part by Key Research and Development Plan ofJiangsu province in 2017 (Industry Foresight and Generic Key Technology)(BE2017035). (Corresponding author: Mu Han.)

    Mu Han is with the School of Computer Science and Communication En-gineering, Jiangsu University, Zhenjiang 212013, China, and also with theCOMPASS Lab, Wayne State University, Detroit, MI 48202 USA (e-mail:[email protected]).

    Ailan Wan is with the School of Computer Science and Communi-cation Engineering, Jiangsu University, Zhenjiang 212013, China (e-mail:[email protected]).

    Fengwei Zhang was with the COMPASS Lab, Department of ComputerScience, Wayne State University, Detroit, MI 48282 USA and is now with the De-partment of Computer Science and Engineering, Southern University of Scienceand Technology, Shenzhen 518000, China (e-mail: [email protected]).

    Shidian Ma is with the Automotive Engineering Research Institute, JiangsuUniversity, Zhenjiang 212013, China (e-mail: [email protected]).

    Color versions of one or more of the figures in this article are available onlineat https://ieeexplore.ieee.org.

    Digital Object Identifier 10.1109/TIV.2020.3027717

    I. INTRODUCTION

    R ECENTLY, the rapid convergence of vehicles and infor-mation technology has resulted in a rapid increase inmodern vehicles connected to the Internet [1]. Such a connectioncan make vehicles become rich sources of data, including bothpersonal and vehicular information. However, it also meansthat vehicles inevitably become lucrative targets for hackers.In 2013, it was reported that a mass production hybrid vehiclehad been cracked by hackers [2], who illegally manipulated thebrake system through the on-board diagnostics (OBD) interface,allowing the hackers to cause traffic accidents and threaten thelives of the occupants. In 2015, the details of security attackson a SUV have been unveiled [3]. The attackers were ableto remotely invade the electronic control units (ECUs) throughin-vehicle entertainment systems, and achieve remote controlof the vehicle’s speed, air conditioning and windshield wipers.Subsequently, in 2017, other researchers hacked some othercars. They showed that they could remotely control the vehi-cle including critical vehicle controls. They showed that theycould remotely control the vehicle including critical vehiclecontrols [4].

    The security loopholes mentioned above originated from thelimitations of the traditional in-vehicle network architecture:1) The traditional in-vehicle network architecture is a closedenvironment, that is insufficiently adapted to the open envi-ronment of modern intelligent connected vehicles (ICVs) [5].Any devices connected to the vehicle can obtain access to thein-vehicle information via Wi-Fi, Bluetooth or OBD interfaces.This increase in interconnections expands the attack surface ofthe vehicle [6], [7]; 2) The communication framework of thein-vehicle network has broadcast characteristics, in which theECUs (nodes) exchange information in the form of plaintext [8].Each ECU can communicate with other ECUs without requiringsource or destination addresses. Hence, an attacker who infil-trates an ECU can easily impersonate any other ECU and finallyachieve remote control of the vehicle.

    In this paper, an ECU access control mechanism for an ICVis designed, which achieves attribute-isolated communicationamong all of the ECUs. The ECUs’ access control mechanismsolves the security threat of unauthorized access. Additionally,it reduces the high bus load of existing in-vehicle architectures.The main contributions of this paper are as follows:

    1) An analysis of the functional attributes of in-vehicle ECUsis performed. According to the impact of the passenger’s func-tional requirements and the traffic environment on vehicles un-der intelligent connected environment, we divide the functional

    2379-8858 © 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.See https://www.ieee.org/publications/rights/index.html for more information.

    Authorized licensed use limited to: Southern University of Science and Technology. Downloaded on November 27,2020 at 07:31:27 UTC from IEEE Xplore. Restrictions apply.

    https://orcid.org/0000-0003-2982-5578https://orcid.org/0000-0003-3365-2526https://orcid.org/0000-0002-0634-9938mailto:[email protected]:[email protected]:[email protected]:[email protected]://ieeexplore.ieee.org

  • 546 IEEE TRANSACTIONS ON INTELLIGENT VEHICLES, VOL. 5, NO. 4, DECEMBER 2020

    attributes of ECUs into five classifications: perception, decision,control, execution, and service.

    2) Based on the above classified ECU functional attributes,we propose an innovative in-vehicle secure attribute-isolatedcommunication architecture. The architecture allows the ECUswith the same functional attributes in the internal network of thevehicle to communicate and isolates the ECUs with differentfunctional attributes, achieving the purpose of access controland reducing the bus load. Then we prove that the proposedarchitecture can resist a forgery attack and an eavesdroppingattack under the random oracle model.

    3) We construct the attribute-isolated communication archi-tecture in a hardware environment and evaluate the architecturewith an in-vehicle network simulator (IVNS). The evaluationresults indicate that the architecture is more efficient than ex-isting schemes in terms of computation time, average storageconsumption and bus load.

    The rest of this paper is organized as follows: In Section II,we review more related works. In Section III, ECU functionalattributes are classified. In Section IV, a novel attribute-isolatedcommunication for the in-vehicle network is proposed. InSection V, we present a theoretical analysis of the security forthe novel architecture. In Section VI, an evaluating experimentfor the novel architecture is conducted and discussed. Finally,Section VII presents the conclusions and future work resultingfrom this study.

    II. RELATED WORK

    Researchers have been moving forward to design a securein-vehicle network architecture to solve the information securityproblem of the in-vehicle network under the ICV environment.The first method to ensure in-vehicle network security was pre-sented by Wolf et al. [9], who constructed a broadcast communi-cation architecture based on the technology of encryption. In thisarchitecture, all of the ECUs are connected to a gateway elec-tronic control unit (GECU), and encrypted secret information istransmitted between the GECU and the others. Another approachto secure in-vehicle communication was proposed by Nilssonet al. [10], who first introduced message authentication codes(MACs) to authenticate the ECUs, overcoming the shortcomingthat an ECU identity is easily impersonated. Nevertheless, theauthentication process increases the load of the controller areanetwork (CAN) bus, making the approach unsuitable for anin-vehicle real-time communication environment.

    Groza et al. proposed a series of lightweight broadcast authen-tication communication solutions for an in-vehicle CAN suchas EPSB (efficient protocols for a secure broadcast in controllerarea networks) and Libra-CAN (a lightweight broadcast authen-tication protocol for controller area networks) [11]–[13]. In theirscheme, ECUs implement broadcast authentication protocolsbased on key-chains and time synchronization, meanwhile thelimited data payload of the CAN data frame in the authenticationprocess is considered. However, the total number of data framesin the vehicle network doubles at minimum when the datapayload is used for MAC in these schemes, since it requiresone data frame containing the original data and at least one data

    frame containing the MAC. Hence, these schemes (includingthe full-length MAC) rapidly increase the load of the CAN busand are not suitable for deployment in the vehicle environment.Jackson et al. went a step further, using a truncated MACcode (Mini-MAC code) to reduce the consumption of in-vehiclelimited resource [14], but this approach weakened the securityof the scheme and interactive information among the ECUs canbe leaked easily.

    In 2012, Robert Bosch GmbH developed a new communi-cation protocol [15], known as CAN with flexible data rate(CAN-FD) to solve the problem of the existing security archi-tectures are inapplicable of directly assisting in-vehicle CANbecause of the limited data payload [16]. The CAN-FD designis based on CAN, with the following advantages: First, it has ahigher bandwidth and a larger data payload. Second, its physicallayer and topologies can be maintained. Soon afterward, Samuelet al. proposed a practical security architecture (PSAC) forin-vehicle CAN-FD [17], [18]. In PSAC, ECUs derive sessionkeys with a GECU in a fixed order and perform authenticationand encryption based on the Keyed-Hash MAC and advancedencryption standard (AES). Patsakis et al. proposed a distributedsecure in-vehicle communication architecture (DSCA) for mod-ern vehicles under a CAN-FD [19]. In the DSCA, the ECUs par-ticipate in a secure multi-party computation scheme to performauthentication and encryption. However, all of the ECUs needto perform decryption, which rapidly increases the bus load,limiting the applicability of this approach in real-time vehiclesystems.

    The above architectures under a CAN-FD do not fully con-sider the access control mechanism, and unauthorized attackerscan also receive the in-vehicle private information. Meanwhile,the bus load of these architectures is high. In this paper, wepropose an isolated architecture based on ECU functional at-tributes under CAN-FD. The proposed architecture not onlyhas an access structure but also can reduce the bus load whencompared with [18], [19].

    III. ECU FUNCTIONAL ATTRIBUTE CLASSIFICATION

    A. Attribute Clustering

    The traditional vehicle is a typical driver-centered system.As shown in Fig. 1, a driver perceives changes of the trafficenvironment through visual and auditory senses. Meanwhile,the driver judges the current environment through their brainand makes driving decisions to control the movement of theirhands and feet, completing the manipulation of the vehicle.

    With the rapid development of artificial intelligence, inter-net technology, communication technology and computer tech-nology, ICV based on electrification, intellectualization andnetworking has become a significant trend in the automotiveindustry. An ICV is mainly embodied by the replacement ofmanual operation with automatic driving, which can compensatefor the shortcomings of the human sensory ability and reducethe driving manipulation intensity. The behaviour and runningstate of the vehicle are controllable and predictable. Therefore,traffic accidents caused by human factors can be eliminated, andtravel paths can be planned according to real-time road condition

    Authorized licensed use limited to: Southern University of Science and Technology. Downloaded on November 27,2020 at 07:31:27 UTC from IEEE Xplore. Restrictions apply.

  • HAN et al.: ATTRIBUTE-ISOLATED SECURE COMMUNICATION ARCHITECTURE FOR INTELLIGENT CONNECTED VEHICLES 547

    Fig. 1. The manipulation of the traditional vehicle [20].

    Fig. 2. The manipulation of the ICV [23].

    information. Ultimately, zero casualties and zero congestion inthe road transport can be achieved [21].

    As shown in Fig. 2, an ICV integrates multiple informationand physical function modules such as an environmental aware-ness module, intelligent decision module, collaborative controlmodule, secure execution module and service module. TheICV can realize safe, comfortable, energy-saving, and efficientdriving, and can eventually replace a new generation of vehiclesoperated by human beings [22].

    These functional modules of the ICV are made possible bya range of 50 to 70 in-vehicle computers networked together,called electronic control units (ECUs) [24].The ECUs exchangeinformation with remote access equipment through wirelesscommunication to sense traffic information. Meanwhile, theECUs transmit operation data and control instructions throughthe in-vehicle network (CAN), as shown in Fig. 3.

    Based on an analysis of the manipulation of the traditionalvehicle, the manipulation of the ICV and the in-vehicle network

    Fig. 3. In-vehicle network system.

    TABLE IATTRIBUTE CLUSTERING OF ECUS

    system, we classify the functional attributes of ECUs into fivefunctional attributes: AttP, AttI, AttC, AttS1 and AttS2, as shownin Table I.

    B. The Scalability of Attribute Clustering

    Based on the above-classified ECU functional attributes, aninnovative in-vehicle attribute-isolated broadcast communica-tion architecture is constructed. We will show that the attributeclustering of ECUs is scalable for the novel architecture.

    1) The scalability of the ECU function attributes. The tra-ditional vehicle is a typical driver-centered system, which per-ceives changes of the traffic environment, judges the currentenvironment and forms driving decisions, completing the manip-ulation of the traditional vehicle. Compared with the traditionalvehicle, an ICV is mainly embodied by replacement of manualoperation. In an ICV system, there are 50 to 70 ECUs networkedtogether, which like the human brain, hands, eyes and feet,achieve environmental awareness, intelligent decision-making,collaborative control, secure execution, and service. If a newECU is added to the ICV, its functional attribute of it should bein the above classified functional attributes.

    Authorized licensed use limited to: Southern University of Science and Technology. Downloaded on November 27,2020 at 07:31:27 UTC from IEEE Xplore. Restrictions apply.

  • 548 IEEE TRANSACTIONS ON INTELLIGENT VEHICLES, VOL. 5, NO. 4, DECEMBER 2020

    Fig. 4. The isolated communication based on ABS access structure.

    2) Attribute communication is scalable, that is, ECUs with anyone of the same attributes can perform isolated-communication.For example, ABS has three functional attributes {AttS1, AttI,AttC }, where AttS1 is the main functional attribute of the ABS.Setting the access structure for the ABS based on its functionalattributes, and allowing other ECUs with one of the abovethree functional attributes to exchange information. Fig. 4 is adiagram of the isolated communication based on the ABS accessstructure, which shows that leaf nodes are composed of ECUfunctional attributes and each non-leaf node consists of a pair ofthreshold values (1, 2). Hence, the other ECUs with functionalattributes {AttS1}, {AttI }, {AttC}, {AttS1, AttI}, {AttS1, AttC},{AttI, AttC}, {AttS1, AttI, AttC} can exchange informationwith the ABS, e.g., the braking ECU with functional attributes{AttS1, AttC} can communicate with the ABS. However, theair conditioner ECU with different functional attributes {AttP,AttS2} cannot communicate with the ABS.

    IV. IN-VEHICLE ATTRIBUTE-ISOLATED COMMUNICATIONARCHUTECTURE

    In this section, based on the above ECU attribute clustering,the proposed in-vehicle attribute-isolated communication archi-tecture is elaborated. The novel architecture consists of a gate-way electronic control unit (GECU) and electronic control units(ECUs) which are equipped in vehicles. The specific functionsare as follows:

    GECU: The GECU1 functions as the trust authority [28] andverifies the identity of the ECUs. Meanwhile, the GECU hassufficient computation power and storage capacity, typicallywell above those of a general ECU.

    ECU: Before being allowed to interact with information, theECUs must register with the GECU. To function as a senderECU, it needs to set an access structure for the receiver ECUsbased on its functional attributes. Two ECUs can only commu-nicate when the functional attributes of a receiver ECU satisfythe access structure.

    The proposed in-vehicle attribute-isolated communica-tion architecture consists of five phases, namely “systeminitialization”, “registration”, “setting the access structure”,

    1GECU is the trusted third party and is free from security leakages.

    TABLE IINOTATIONS AND DESCRIPTIONS

    “attribute-isolated communication” and “updating the ciphertextand attribute private key”.

    P1. System initialization. The GECU publishes the publicparameters and generates the master key.

    P2. Registration. The ECUs register their identities informa-tion to the GECU.

    P3. Setting the matching strategy. We set the matching strategyfor the access structure of the ciphertext and the attribute privatekey.

    P4. Attribute-isolated communication. The ECUs performattribute-isolated communication based on the matching strat-egy.

    P5. Updating the ciphertext and attribute private key. Thisphase prevents attackers from obtaining in-vehicle private data.

    In the following, we present the details of each phase. Thenotations used in the five phases are listed in Table II.

    A. System Initialization

    Step 1: The GECU inputs the secure parameter k and gen-erates two additive groups G0 and a multiplicative group G1.Define a bilinear mapping e : G0 ×G0 → G1, and two genera-tors p1, p2 of G0 and G1, respectively, where G0 and G1 haveprime order q.

    Step 2: The GECU randomly choosesα, β, θ ∈ Z∗q and a hashfunction H : {0, 1}∗ → Z∗q .

    Step 3: The GECU publishes the public parameters:{G0, G1, e, H, p1, p2, θp2, θ2p2, Y = e(p1, p2)α(β−1),

    e(p1, p2)αβ}. Meanwhile, the public key is PKGECU =

    SKGECUP2, and the master key is MK = SKGECU = αp1.

    B. Registration

    After completing the system initialization, the GECU per-forms the registration phase to verify the ECU identity, prevent-ing attackers from impersonating the ECU identity. Algorithm 1indicates the registration process. The concrete steps are asfollows.

    Step 1: ECU1 sends registration request information to theGECU. The registration information is generated as follows.

    1) ECUI chooses (PKECUI , SKECUI ) as its public andprivate key pairs, where SKECUI = r1(r1 ∈ Z∗q), PKECUI =SKECUIp2.

    Authorized licensed use limited to: Southern University of Science and Technology. Downloaded on November 27,2020 at 07:31:27 UTC from IEEE Xplore. Restrictions apply.

  • HAN et al.: ATTRIBUTE-ISOLATED SECURE COMMUNICATION ARCHITECTURE FOR INTELLIGENT CONNECTED VEHICLES 549

    2) ECUI computes H(IDECUI ) by its identity IDECUIand selects a secret random number r2 (r2 ∈ Z∗q) to generatethe request information (VECUI ,WECUI ) where (VECUI =PKECUIH(IDECUI )), WECUI = r2p2.

    3) ECUI signs the request information (VECUI ,WECUI )through SKECUI to obtain the signature information SigI =sigSKECUI (VECUI‖WECUI ).

    4) ECUI computes H(IDECUI ) and uses PKGECUto encrypt VECUI , WECUI and H(IDECUI ). ECUI sendsMsg1(EPKGECU (VECUI‖WECUI‖H(IDECUI ))‖SigI‖t) toGECU.

    Step 2: After receiving Msg1, the GECU takes the followingactions to verify the legitimacy of ECUI .

    1) The GECU verifies the validity of the timestamp by for-mula (1), where t′ is the current time. T is the maximum timedifference allowed for the vehicle.

    (Δt = t′ − t) < T (1)2) Once verified successfully, the GECU decrypts EPKGECU

    (VECUI‖WECUI‖H(IDECUI )) in Msg1 by SKGECU andobtains VECUI , WECUI and H(IDECUI ).

    3) The GECU confirms the correctness of the requestinformation by verifying SigI . The GECU uses formula(2) to verify SigI . If V erPKECUI (VECUI‖WECUI , SigI) =V erPKECUI (VECUI‖WECUI , SigSKECUI (VECUI‖WECUI ))= true, it indicates that Msg1 has not been forged. Otherwise,the GECU discards Msg1.

    V erPKECUI (x, y) =

    {true y = sigSKECUI (x)

    false y �= sigSKECUI (x)(2)

    wherex is the request information (VECUI ,WECUI ) and y is thesignature information SigI = sigSKECUI (VECUI‖WECUI ).

    4) GECU randomly selects r3 ∈ Z∗q and computes R =WECUI + r3p2, L = r3 + SKGECUVECUI . GECU verifiesthe legal identity of ECUI by formula (3). If formula (3) isestablished, it indicates that the identity of ECUI is legal.Otherwise, ECUI is forged.

    LP +WECUI = R+ PKGECUVECUI (3)

    The process of the verification is shown in formula (4). Ifformula (4) is established, it indicates that the identity of ECUIis legal. Otherwise, ECUI is forged,and the GECU refuses therequest information and terminates the session.

    LP +WECUI = (r3 + SKGECUVECUI )p2 + r2p2

    = (r3 + SKGECUVECUI + r2)p2

    = (r2 + r3)p2 + SKGECUVECUIp2

    = R+ PKGECUVECUI (4)

    5) After verifying the legal identity of ECUI , the GECUstores the set of legal ECUs and returns the successful regis-tration information Msg2(EPKGECU (H(IDECUI ))‖t′) to theECU.

    Step 3: ECUI decrypts EPKGECU (H(IDECUI )) in Msg2through SKECUI . This indicates that ECUI successfully reg-isters in the GECU.

    Fig. 5. Matching strategy for the access structure and attribute private key.

    Algorithm 1: ECU Registration Protocol(ECU_REGISTRA-TION).

    1: ECUI : Generate the registration request information2: ECUI → GECU :

    Msg1(EPKGECU (VECUI ‖WECUI ‖H(IDECUI ))‖SigI‖t)where VECUI = PKECUIH(IDECUI ), WECUI = r2p2

    3: GECU: Verify the legitimate identity of ECUI4: if (Δt = t′ − t) < T is valid then

    GECU: Decrypt EPKGECU (VECUI ‖WECUI ‖H(IDECUI ))in Msg1 by SKGECU and verify Sig1elseGECU: Refuse the request informationendif

    5: if V erPKECUI (Sig1, VECUI ‖WECUI ) = ture, thenGECU: Compute R = WECUI + r3p2,L = r3 + SKGECUVECUIelseGECU: Refuse the request information

    6: if Lp2 +WECUI = R+ PKGECUVECUI then GECU: Thelegal identity of the ECU is successfully authenticated, and thenGECU → ECUI :

    Msg2(EPKGECU (H(IDECUI ))‖t′)endif

    7: ECUI : Successfully registeredendif

    C. Setting the Matching Strategy

    After the ECUs successfully register in the GECU, we setthe matching strategy for the access structure of the ciphertextand the attribute private key. As shown in Fig. 5, the in-vehicleECUs are logically separated from their access rights. TheECUs are described by functional attributes and obtain attributeprivate keys according to their functional attributes. The ECUscan communicate only when their attribute private keys can

    Authorized licensed use limited to: Southern University of Science and Technology. Downloaded on November 27,2020 at 07:31:27 UTC from IEEE Xplore. Restrictions apply.

  • 550 IEEE TRANSACTIONS ON INTELLIGENT VEHICLES, VOL. 5, NO. 4, DECEMBER 2020

    Fig. 6. Access structure of ABS.

    Fig. 7. In-vehicle attribute-isolated communication.

    decrypt the ciphertext. Therefore, the matching strategy realizesthe isolated communication among the ECUs with the samefunctional attributes.

    For example, the antilock brake system (ABS), which canquickly judge the lock state of a wheel according to the speedsignal from each wheel speed ECU to ensure the vehicle safety,has three functional attributes: AttI: the perception functionattribute, AttC: the collaborative control function attribute, andAttS1: the secure execution function attribute. We set the accessstructure for ABS based on its functional attributes, as shown inFig. 6. In addition,the ABS generates the attribute private keybased on its functional attributes. Therefore, the attribute privatekey matches the access structure based on the ABS functionalattributes.

    D. Attribute-Isolated Communication

    Based on the above matching strategy and ciphertext-policyattribute-based encryption algorithm (CP-ABE), the ECUs per-form attribute-isolated communication, thereby allowing onlythe authorized ECUs to obtain the in-vehicle private information.The specific design of our scheme is shown in Fig. 7. We takeECUI and ECUJ to show how the ECUs can communicate,ECUI and ECUJ have the same functional attributes Atti. Theconcrete steps are as follows.

    1) ECUI Generates the Ciphertext: ECUI performs thefollowing steps to broadcast the ciphertext:

    i) ECUI sets the access structure ACPI as shown in Fig. 1.Every non-leaf node of the tree represents a threshold kr and thenumber of a children node numx (1 ≤ numx ≤ 5). Each leafnode r of the tree is described by its functional attributes.

    ii)ECUI chooses s ∈ Z∗q and a polynomial qr of degree dr =kr − 1 inACPI , where kr is the threshold of the node r inACPI ,qr(0) = s. Let Nr denote the set of all leaf nodes in ACPI .

    Fig. 8. Access Structure.

    ECUI computes the ciphertext by formula (6) as follows:

    CTIJ = (ACPI , C̃, C, C′, ∀r ∈ Nr : C ′r, C ′′r ) (5)

    Where C̃ = e(p1, p2)αβsM , C = sp1, C ′ = Y s, C′r =

    qr(0)H(Atti)p2 + qr(0)θ2p2, andC

    ′′r = qr(0)θp2).

    Meanwhile, ECUI broadcasts MsgB1(CTI ||T1) in the ve-hicle.

    2) ECUJ ObtainsM From the Ciphertext: ECUJ performsthe following steps to achieve M from the broadcast ciphertext.

    i) ECUJ takes Atti,MK as an input, where Atti isthe functional attribute of ECUI . ECUJ randomly selectskj , lj ∈ Z∗q for each attribute Atti ∈ Sj and then computeshj = H(Atti). Subsequently, ECUJ computes the attributeprivate key SKECUJCP−ABE as: SK

    ECUJCP−ABE = (Dj , ∀Atti ∈ Sj :

    D′j , D′′j ) where Dj = αp2 + ljkjp2, D

    ′j = kjp1 + hjp1, D

    ′′j =

    ljkjθp1.ii) ECUJ uses the recursive algorithm DecryptNode(CTI ,

    SKECUJCP−ABE , r) and inputs CTI , SKECUJCP−ABE and node r

    of the access structure ACPI . SKECUJCP−ABE is related to the

    attribute set Sj and the attribute Atti. The definition ofDecryptNode(CTI , SK

    ECUJCP−ABE , r) is as follows:

    DecryptNode(CTI , SKECUJCP−ABE , r) =

    e(D′j , C

    ′r)

    e(D′′j , C

    ′′r)

    = e(ljkjp1, qr(0)p2)

    = e(p1, p2)ljkjqr(0)

    (6)

    We denote:B = DecryptNode(CTI , SK

    ECUJCP−ABE , r) = e(p1,

    p2)ljkjs, where qr(0) = s.

    After performing DecryptNode(CTI , SKECUJCP−ABE , r),

    ECUJ can obtain M as follows:

    Decrypt(CTI ,SKECUJCP−ABE)=

    B · C̃e(C,Dj) · C ′

    =e(p1,p2)

    ljkjs·e(p1, p2)αβsMe(p1,p2)s(α+ljkj)·e(p1,p2)α(β−1)s

    =M · e(p1, p2)s(α−α)

    =M (7)

    E. Updating the Ciphertext and Attribute Private Key

    The proposed attribute-isolated communication architectureintroduces a counter mechanism in the traditional CP-ABE

    Authorized licensed use limited to: Southern University of Science and Technology. Downloaded on November 27,2020 at 07:31:27 UTC from IEEE Xplore. Restrictions apply.

  • HAN et al.: ATTRIBUTE-ISOLATED SECURE COMMUNICATION ARCHITECTURE FOR INTELLIGENT CONNECTED VEHICLES 551

    scheme to update the ciphertext and attribute private key of eachECU. We specify that the counter is integrated into the accessstructure when the sender ECU generates the ciphertext eachtime, hence the receiver ECUs must synchronize the countersand update their own attribute private key. This effectivelyprevents attackers from obtaining in-vehicle private data. Theconcrete steps are as follows.

    1) ECUI Updates the Ciphertext: When a vehicle stalls,any broadcast interaction ends, and ECUI will invalidate itsprevious ciphertext CTI . The next time the vehicle is started,ECUI must generate a new ciphertext as follows.

    i)ECUI manages its own counter valueCTRI and computesH(Atti ⊕ CTRI), and then generates the new ciphertext CT ′Iby formula (8).

    CT ′I = ACPI , C̃, C, C′, ∀r ∈ Nr : C ′rnew, C ′′r ) (8)

    where C̃ = e(p1, p2)αβsM , C = sp1, C ′ = Y s, C ′rnew =qr(0)H(Atti ⊕ CTRI)p2 + qr(0)θ2p2, andC ′′r = qr(0)θp2).

    ii) ECUI broadcasts the new ciphertext CT ′I in the vehicleand increments CTRI .

    2) ECUJ Updates the Attribute Private Key: After receiv-ing the ciphertext, ECUJ manages the counter of ECUJand computes h′j = H(Atti ⊕ CTRI), and then generatesthe new attribute private key SK ′ECUJCP−ABE as SK

    ′ECUJCP−ABE =

    (Dj , ∀Atti ∈ Sj : D′iknew, D′′ik) where Dik = αp2 + ljkjp2,D′iknew = kjp1 + h

    ′jp1, and D

    ′′j = ljkjθp1. ECUJ increments

    the counter CTRI of ECUI .

    V. SECURITY ANALYSIS OF THE PROPOSED SCHEME

    In this section, we theoretically prove that the proposed archi-tecture can resist forgery attack and eavesdropping attack underthe random oracle model.

    Theorem 1: Assuming that the Discrete Logarithm (DL) as-sumption is established, the ECU ID in the proposed attribute-isolated architecture can resist a forgery attack.

    Proof: Assume that the attacker A can fake the real iden-tity information IDECUI of the legal ECU and generate avalidmessage Msg1, that is, A can calculate the effective valueVECUI = PKECUIH(IDECUI ) of Msg1. The advantage of Aattack success isAdvA. We useA to construct an algorithmADLto solve the DL problem. �

    ADL randomly chooses θ ∈ Z∗q , publishes the public param-eters: {G0, G1, e,H, p1, p2, θp2, θ2p2, Y = e(p1, p2)a(b−1),e(p1, p2)

    ab} and saves the master key MK = ap2 secretly. Acan make queries about ADL to qDL times.

    Query: A makes queries about IDECUI , and algorithm ADLreturns VECUI = PKECUIH(IDECUI ) to A.

    Challenge: After A receives VECUI , A uses (PKECUI ,VECUI ) to call algorithm ADL and lets H(IDECUI ) = a. Thatis given PKECUI , aPKECUI , compute a.

    The advantage of A challenge success in this process isAdvA = qDL ·AdvDL. As can be seen from the difficult prob-lems described in the preliminaries, the advantage AdvA ofthe algorithm in successfully solving the DL problem in thepolynomial time is negligible, hence the attacker A cannotcounterfeit the ECU ID.

    Theorem 2: Provided that the DL assumption is established,the ECU attributes in the proposed attribute-isolated architecturecannot be obtained.

    Proof: Assume that the attacker A can obtain the real at-tributes Atti of the ECU, that is, A can calculate the effectivevalue H(Atti)p1 in the ECU attribute private key SK

    ECUJCP−ABE .

    The advantage of A successful attack is AdvA. We use A toconstruct algorithm ADL to solve DL problem. �ADL randomly chooses θ ∈ Z∗q , publishes the pub-

    lic parameters: {G0, G1, e,H, p1, p2, θp2, θ2p2, Y = e(p1,p2)

    a(b−1), e(p1, p2)ab} and saves the master key MK = ap2secretly. A can make queries about ADLto qDL times.

    Query: A makes queries about the real attributes Atti of theECU, and ADL returns H(Atti)p1 to A.

    Challenge: After A receives H(Atti)p1, A uses(p1, H(Atti)p1) to call algorithm ADL and lets H(Atti) = a.That is given p1, ap1, compute a. The advantage of A challengesuccess in this process isAdvA = qDL ·AdvDL. The advantageAdvA of the algorithm in successfully solving the DL problemin the polynomial time is negligible. Hence the attackerA cannotobtain the ECU attributes and generate the ECU attribute privatekey.

    Theorem 3: Assuming the DBDH (Determine Bilinear Diffie-Hellman) problem is difficult, then the scheme designed in thispaper is CCA (Chosen-Ciphertext Attack) secure.

    Proof: Challenger C randomly chooses θ ∈ Z∗q , publishesthe public parameters: {G0, G1, e,H, p1, p2, θp2, θ2p2, Y =e(p1, p2)

    a(b−1), e(p1, p2)ab} and saves the master key MK =ap2. �

    Phase 1: C generates the attribute private key accord-ing to the attribute set Si of the ECU: SK

    ECUICP−ABE(Di).

    Then C generates CT and broadcasts it according to formula(5) in the attribute-isolated communication process: CT =ACP , C̃, C, C

    ′, C ′r, C′′r ).

    The attacker A intercepts ciphertext CT from the broadcastmessages by eavesdropping and sends CT to C. C uses thedecryption algorithm to obtain M and transmits it to A.

    Challenge:A chooses two equal messagesM0,M1 and accessstructure A∗CP . A sends (M0,M1, A

    ∗CP ) to C. C sets r to be

    the set of the root node in A∗CP after receiving (M0,M1, A∗CP ).

    Then C randomly selects b′ ∈ {0, 1} and computes:

    CT ∗ = (A∗CP , C̃ = Z ·Mb′ ,

    C = cp1, C′ =

    Z

    e(ap1, cp2),

    ∀r ∈ Nr :C ′r = qr(0)H(atti)p2 + qr(0)θ

    2p2,

    C ′′r = qr(0)θp2)

    Finally, C returns CT ∗ to A.Phase 2: All of the queries in Phase 1 can be performed during

    Phase 2. However, if A asks for the decryption algorithm inthe attribute-isolated communication phase, C will abort thesimulation.

    Authorized licensed use limited to: Southern University of Science and Technology. Downloaded on November 27,2020 at 07:31:27 UTC from IEEE Xplore. Restrictions apply.

  • 552 IEEE TRANSACTIONS ON INTELLIGENT VEHICLES, VOL. 5, NO. 4, DECEMBER 2020

    Guess: A outputs b′′ ∈ {0, 1} as a guess for b′. If b′′ = b′, Awill win the game. Otherwise, A fails. If the attacker A canwin the CCA game in polynomial time with non-negligibleadvantage ε, then C can solve the DBDH enlarge 20% problemwith non-negligible advantage ε′, where ε′ ≥ 12 (ε− δ) and δ isa negligible advantage. The probability analysis is as follows.

    If Z = e(p1, p2)abc, we can achieve thatPr[A(p1, p2, ap1, bp1, cp1, ap2, bp2, cp2, e(p1, p2)

    abc) = 1]= Pr[b′′ = b′] where |Pr[b′′ = b′]− 12 | ≥ ε. Otherwise, if Z israndomly chosen from G1, then

    Pr[A(p1, p2, ap1, bp1, cp1, ap2, bp2, cp2, Z) = 1] = Pr[b′′ = b′]

    Where |Pr[b′′ = b′]− 12 | ≤ δ and δ is the advantage of break-ing the semantic security and can be ignored. Hence, we canpresent that

    |Pr[A(p1, p2, ap1, bp1, cp1, ap2, bp2, cp2, e(p1, p2)abc) = 1]− Pr[A(p1, p2, ap1, bp1, cp1, ap2, bp2, cp2, Z) = 1]|≥ ε− δTherefore, we can conclude that the proposed scheme satisfies

    CCA secure.

    VI. SIMULATION AND EVALUATION

    In this section, we first constructed the attribute isolatedarchitecture using STMicroelectronics’s automotive microcon-trollers to extract the hardware parameters and then evaluated thearchitecture using the software In-Vehicle Network Simulator(IVNS). We compared the proposed architecture with the archi-tecture suggested in [18] and [19] in terms of the computationtime, average storage consumption, and bus load.

    A. Simulation

    1) The Construction of the Attribute Isolated Architecture inthe Hardware Environment: To ensure that the software simu-lation follows reality as closely as possible, the simulation canbe parametrized with measurements from real hardware. In thehardware-constructed experiment of the attribute isolated archi-tecture, we used 12 STM32 microcontrollers with 12 addressnumbers of 0X0446 to 0X0451 as ECU nodes, and the 0X0449address number node was used as the GECU. We first trans-planted the portable system contiki in the integrated environmentof keil’s MDK5 and compiled the codes used in the experiment.As shown in Fig. 9, we built an attribute isolated architecture.The time parameters of the hardware were exported through theserial port. The specifications of the tools used in the hardwareexperiment and software simulation are shown in Table III.

    i) Extraction of the registration time parameters: We mea-sured the registration time of 12 ECUs in the attribute-isolatedarchitecture respectively, as shown in Table IV. The averageregistration time for an ECU to perform one registration isapproximately 0.36 ms. The average time that the GECU verifiesone ECU is approximately 0.54 ms.

    ii) Extraction of the encryption and decryption time parame-ters: The average execution time for encryption, attribute privatekey generation and decryption were measured by implementing

    Fig. 9. Construction environment of the attribute-isolated architecture.

    TABLE IIITOOLS USED FOR THE SIMULATION

    TABLE IVREGISTRATION TIME EXTRACTED FROM THE HARDWARE

    the CP-ABE algorithms on 11 ECUs. We measured the averagekey generation time, the average encryption time, successfuldecryption time and failed decryption time from 1 byte to 100bytes, as shown in Fig. 10. The average time for an ECU togenerate the attribute private key is approximately 3 ms. Theaverage encryption time on hardware is 4.8 ms. The average timefor an ECU to fail to achieve decryption is 1.6 ms. The averagetime for an ECU to successfully achieve decryption is 7.5 ms.

    2) IVNS Simulation: Then, to verify the performance of theproposed attribute isolated communication among the ECUs,the time parameters extracted from the hardware experimentare imported into a python database. We built a 64-bit systemenvironment based on Ubuntu under the PC, with 1.6 GHz CPU

    Authorized licensed use limited to: Southern University of Science and Technology. Downloaded on November 27,2020 at 07:31:27 UTC from IEEE Xplore. Restrictions apply.

  • HAN et al.: ATTRIBUTE-ISOLATED SECURE COMMUNICATION ARCHITECTURE FOR INTELLIGENT CONNECTED VEHICLES 553

    Fig. 10. CP-ABE performance for hardware implemention.

    Fig. 11. Computation time.

    and 8 GB RAM. Then, we built a simulator environment basedon In-Vehicle Network Simulator (IVNS) which is developed byArtur Mrowca et al. [29]. To export the communication perfor-mance results, we created a monitor tag in the communicationlayer of the IVNS. The monitor tag outputs the simulation resultsinto CSV files. The analysis of the simulation results is shownin the next subsection.

    B. Evaluation and Comparison

    In this subsection, we compare the proposed architecture withthe architecture PSAC suggested in [18] and the architectureDSCA in [19] in terms of the computation time, averagestorage consumption, and bus load. For the convenience of thedescription, our proposed architecture is denoted as Ours.

    1) Computation Time: We measure the computation timefrom the time that the ECUs process a message and transmitsthe encrypted messages in our scheme. The simulation result isshown in Fig. 11, if ECUs are added to the system for all of thearchitectures, the measured computation time needed to executethe simulation increases with an increasing number of ECUs. Inaddition, the DSCA performs the slowest, while the computationtime for the PSAC with 100 messages is nearly equal to that ofour architecture with 200 messages. Furthermore, the slope ofthe curves is higher when ECUs send more messages. Hence,for the DSCA, the computation time for 40 ECUs and 200messages is 849.78 ms and for 100 ECUs, the computation timeis 4736.87 ms. For PSAC it is 513.47 ms and 1403.77 ms, whilefor our architecture, it is 408.77 ms and 1174.88 ms. Hence, thecomputation time of the proposed attribute-isolated architectureis less than that of the PSAC and DSCA.

    Fig. 12. Average memory storage.

    Fig. 13. Bus load comparisons.

    2) Average Storage Consumption: The average memory us-age behaves differently for the three architectures, as shown inFig. 12. While for our architecture and PSAC, the average mem-ory usage is nearly equal when the ECUs are added to the system,for the DSCA, the average memory usage increases linearly.This is because the DSCA needs to cache more authenticationand encryption messages. For the DSCA, the average memoryusage for 120 ECUs and 200 messages is 159.98 MB and for 200ECUs, the average memory usage is 261.73 MB. For the PSAC,the average memory usage is 81.56 MB and 139.78 MB, whilefor our architecture, the average memory usage is 78.69 MB and125.78 MB. Additionally, the DSCA requires more events thanother architectures per new ECU, as a message exchange is morecostly than our architecture or the PSAC and more ECUs meanmore receivers. Hence the DSCA curve increases rapidly. For thePSAC, each ECU performs authentication and encryption anddecryption to cache messages. The additional monitor informa-tion that results from more ECUs thus requires more receiversin the DSCA. For our attribute-isolated architecture, the curveslowly increases. The number of receivers is less than the numberof ECUs in the vehicle and only specified ECUs can cachein-vehicle data. From this perspective, our architecture attainsreasonable memory usage in comparison with the memory usageof the DSCA and PSAC.

    3) Bus Load: The bus load rate is the sum of the bus percent-ages occupied by all data frames, and is an important indicatorfor measuring the communication performance of an in-vehiclenetwork. We fixed the baud rate of the CAN-FD at 500 Kbpsand evaluated the bus load for different cycles and numberof messages. Fig. 13 shows the bus load of our architecture

    Authorized licensed use limited to: Southern University of Science and Technology. Downloaded on November 27,2020 at 07:31:27 UTC from IEEE Xplore. Restrictions apply.

  • 554 IEEE TRANSACTIONS ON INTELLIGENT VEHICLES, VOL. 5, NO. 4, DECEMBER 2020

    compared to that of the PSAC and DSCA in terms of the numberof messages. In the case of the DSCA, the bus load increaseby approximately 50% due to the new message exchange andencryption. The bus load of the PSAC is slightly higher thanthat of our architecture since the PSAAC additionally has totransmit as many MAC messages as receivers. When there are100 messages in the vehicle, the periods are 10 ms, 20 ms and50 ms, the bus load of DSCA is 34.39%, that of PSAC is 22.34%,while the bus load of our architecture is 18.96%. Hence, the busload of DSCA and PSAC are higher than that of our attributeisolated communication architecture. The proposed architecturecan be well applied to the in-vehicle real-time environment.

    VII. CONCLUSION

    In this paper, a secure and efficient attribute-isolated au-tomotive architecture was proposed. First, an analysis of thefunctional attributes of all of the in-vehicle ECUs in an intelligentconnected environment and a division of the functional attributesof the ECUs into five classifications were performed. Second,based on the above-classified attributes, we demonstrated asecure attribute-isolated communication architecture. The ECUshave different access rights, allowing only the ECUs with thesame functional attributes in the internal network of the vehicleto communicate. Then, it was proven that the proposed architec-ture could resist both forgery and eavesdropping attacks underthe random oracle model. Finally, the secure attribute-isolatedcommunication architecture was constructed in a hardware en-vironment and evaluated with the IVNS. The evaluation resultsshowed that the average memory usage with 120 ECUs and100 messages is below 40 MB and the bus load can be reducedto 18.96% using the proposed security architecture comparedwith existing architectures. Our results confirm that the proposedarchitecture is suitable for an application to in-vehicle real-timeenvironments.

    In the future work, ICV will face driverless environments.These driverless cars can use nodes to perform edge computingand collect information for decision-making [30]. We will usegateways as nodes to enhance the collection capabilities of edgecomputing and ensure the efficiency and real-time performanceof the automotive system. Therefore, securing automotive archi-tecture based on edge computing will be the focus of our futureresearch.

    REFERENCES

    [1] W. Zeng, M. A. Khalid, and S. Chowdhury, “In-vehicle networks outlook:Achievements and challenges,” IEEE Commun. Surv. Tut., vol. 18, no. 3,pp. 1552–1571, Jan. 2017.

    [2] J.-S. Yang, H.-J. Lee, M.-W. Park, and J. Eom, “Security threats on nationaldefense ICT based on iot,” Proc. Adv. Sci. Tech. Lett., vol. 97, pp. 94–98,Jun. 2015.

    [3] C. Miller and C. Valasek, “Remote exploitation of an unaltered passengervehicle,” Proc. Black. Hat., vol. 2015, pp. 1–94, 2015.

    [4] S. Nie, L. Liu, and Y. Du, “Free-fall: HackingTesla from wireless to canbus,” Proc. Black. Hat., vol. 2017, pp. 1–16, 2017.

    [5] L. B. Othmane, H. Weffers, M. M. Mohamad, and M. Wolf, “A surveyof security and privacy in connected vehicles,” in Proc. Wireless SensorMobile Ad-Hoc Netw., 2015, pp. 217–247.

    [6] K.-T. Cho and K. G. Shin, “Viden: Attacker identification on in-vehiclenetworks,” in Proc. ACM SIGSAC Conf. Comput. Commun. Secur., 2017,pp. 1109–1123.

    [7] P. Subke, M. Moshref, A. Vach, and M. Steffelbauer, “Measures to preventunauthorized access to the in-vehicle e/e system, due to the securityvulnerability of a remote diagnostic tester,” SAE Int. J. Cars. Elect. Syst.,vol. 10, no. 2, pp. 422–429, Mar. 2017.

    [8] P. Mundhenk et al., “Security in automotive networks: Lightweight au-thentication and authorization,” ACM Trans. Des. Automat. Electron. Syst.,vol. 22, no. 2, pp. 1–27, Mar. 2017.

    [9] M. Wolf and A. Osterhues, “Safe messages modern cryptography protectsautomotive ecus,” ATZelektronik worldwide, vol. 8, no. 2, pp. 38–43,Mar. 2013.

    [10] D. K. Nilsson, U. E. Larson, and E. Jonsson, “Efficient in-vehicle delayeddata authentication based on compound message authentication codes,” inProc. 68th IEEE Int. Conf. Veh. Technol., 2008, pp. 1–5.

    [11] B. Groza and P.-S. Murvay, “Broadcast authentication in a low speedcontroller area network,” in Proc. Int. Conf. E-Bus Telecommun., 2011,pp. 330–344.

    [12] B. Groza, S. Murvay, A. van Herrewege, and I. Verbauwhede, “Libra-can: A lightweight broadcast authentication protocol for controllerarea networks,” in Proc. Int Conf. Cryptol. Netw. Secur., 2012,pp. 185–200.

    [13] B. Groza and S. Murvay, “Efficient protocols for secure broadcast incontroller area networks,” IEEE Trans. Ind. Inform., vol. 9, no. 4,pp. 2034–2042, Nov. 2013.

    [14] J. Schmandt, A. T. Sherman, and N. Banerjee, “Mini-MAC: Raising the barfor vehicular security with a lightweight message authentication protocol,”Veh. Commun., vol. 9, pp. 188–196, Jul. 2017.

    [15] S. Tuohy, M. Glavin, C. Hughes, E. Jones, M. Trivedi, and L. Kilmartin,“Intra-vehicle networks: A review,” IEEE Trans. Intell. Transp. Syst.,vol. 16, no. 2, pp. 534–545, Apr. 2014.

    [16] F. Hartwich et al., “Can with flexible data-rate,” in Proc. Vector. Can., Inc.,2012, pp. 1–9.

    [17] S. Woo, H. J. Jo, and D. H. Lee, “A practical wireless attack on theconnected car and security protocol for in-vehicle can,” IEEE Trans. Intell.Transp. Syst., vol. 16, no. 2, pp. 993–1006, Apr. 2015.

    [18] S. Woo, H. J. Jo, I. S. Kim, and D. H. Lee, “A practical security architecturefor in-vehicle CAN-FD,” IEEE Trans. Intell. Transp. Syst., vol. 17, no. 8,pp. 2248–2261, Aug. 2016.

    [19] C. Patsakis, K. Dellios, and M. Bouroche, “Towards a distributed secure in-vehicle communication architecture for modern vehicles,” Comput. Secur.,vol. 40, pp. 60–74, Feb. 2014.

    [20] A. Rehman, M. M. Rathore, A. Paul, F. Saeed, and R. W. Ahmad, “Ve-hicular traffic optimisation and even distribution using ant colony in smartcity environment,” IET Intell. Transp. Syst., vol. 12, no. 7, pp. 594–601,Sep. 2018.

    [21] D. Yang et al., “Intelligent and connected vehicles: Current statusand future perspectives,” Sci. China. Technol. Sci., vol. 61, no. 10,pp. 1446–1471, Sep. 2018.

    [22] B. Ran, H. Tan, J. Zhang, and Q. U. Xu, “Development status and trendof connected automated vehicle highway system,” J. Auto. Safe. Energy.,vol. 9, no. 2, pp. 119–130, May. 2018.

    [23] E. Ohn-Bar and M. M. Trivedi, “Looking at humans in the age of self-driving and highly automated vehicles,” IEEE Trans. Intell. Transp. Syst.,vol. 1, no. 1, pp. 90–104, Jun. 2016.

    [24] A. Humayed, J. Lin, F. Li, and B. Luo, “Cyber-physical systems security-asurvey,” IEEE Internet Things J., vol. 4, no. 6, pp. 1802–1831, May 2017.

    [25] L. Zhang and G. Orosz, “Motif-based design for connected vehiclesystems in presence of heterogeneous connectivity structures and timedelays,” IEEE Trans. Intell. Transp. Syst., vol. 17, no. 6, pp. 1638–1651,Jun. 2016.

    [26] J. Wang, D. Yang, and X. Lian, “Research on electrical/electronic archi-tecture for connected vehicles,” in Proc. IET Int. Conf. Intell. ConnectedVeh., 2016, pp. 1–6.

    [27] M. Zhou, X. Qu, and S. Jin, “On the impact of cooperative autonomousvehicles in improving freeway merging: A modified intelligent drivermodel-based approach,” IEEE Trans. Intell. Transp. Syst., vol. 18, no. 6,pp. 1422–1428, Sep. 2017.

    [28] J. H. Kim, S.-H. Seo, N.-T. Hai, B. M. Cheon, Y. S. Lee, and J. W.Jeon, “Gateway framework for in-vehicle networks based on can, flexray,and ethernet,” IEEE Trans. Veh. Technol., vol. 64, no. 10, pp. 4472–4486,Oct. 2014.

    [29] P. Mundhenk, A. Mrowca, S. Steinhorst, M. Lukasiewycz, S. A. Fahmy,and S. Chakraborty, “Open source model and simulator for real-timeperformance analysis of automotive network security,” ACM Sig. Rev.,vol. 13, no. 3, pp. 8–13, Jun. 2016.

    [30] W. Yu et al., “A survey on the edge computing for the internet of things,”IEEE Access, vol. 6, pp. 6900–6919, Nov. 2017.

    Authorized licensed use limited to: Southern University of Science and Technology. Downloaded on November 27,2020 at 07:31:27 UTC from IEEE Xplore. Restrictions apply.

  • HAN et al.: ATTRIBUTE-ISOLATED SECURE COMMUNICATION ARCHITECTURE FOR INTELLIGENT CONNECTED VEHICLES 555

    Mu Han (Member, IEEE) was born in 1980. Shereceived the Ph.D. degree from the School of Com-puter Science and Technology, Nanjing Universityof Science and Technology, China, in 2011. She iscurrently an Associate Professor with the School ofComputer Science and Communication Engineering,Jiangsu University. Her research interests includecryptography, security and communication in vehiclenetwork, the design of security protocols for smartcar and Information Security, etc.

    Ailan Wan was born in Jiangsu Province, China.She received the B.S. degree from Jiangsu University,Zhenjiang, in 2016. She is currently working towardthe M.S. degree with the Department of ComputerScience and Communication Engineering, JiangsuUniversity. Her research interests include informationsecurity, cryptography, security of Electronic ControlUnit in vehicular network, controller area networksecurity.

    Fengwei Zhang received the Ph.D. degree in com-puter science from George Mason University. He isan Associate Professor with Department of ComputerScience and Engineering, Southern University of Sci-ence and Technology. He was an Assistant Professorand the Director of the COMPASS Lab with Depart-ment of Computer Science, Wayne State University.His primary research interests include in the areas ofsystems security, with a focus on trustworthy execu-tion, hardware-supported security, transparent mal-ware analysis, and plausible deniability encryption.

    Shidian Ma received the master’s degree from theSchool of mechanical and automotive engineering,Hefei University of Technology, China, in 2005. Heis currently an Associate Professor with School ofAutomotive Engineering Research Institute, JiangsuUniversity. His research interests include automo-tive electronic control technology, road traffic activesafety prevention and control, security and commu-nication of electronic control system.

    Authorized licensed use limited to: Southern University of Science and Technology. Downloaded on November 27,2020 at 07:31:27 UTC from IEEE Xplore. Restrictions apply.

    /ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 150 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages false /GrayImageDownsampleType /Bicubic /GrayImageResolution 1200 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 1.00083 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages false /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 1200 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages false /MonoImageDownsampleType /Bicubic /MonoImageResolution 1600 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.00063 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile (None) /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName () /PDFXTrapped /False

    /CreateJDFFile false /Description >>> setdistillerparams> setpagedevice