1 Introduction

The development of technological innovations has led to the communication enabled between vehicles with the aid of V2V communication and V2I communication. The VANET is characterised by the mobile and self-organising nodes. VANET’s provide timely updates on safety related information, Entertainment updates etc., which are broadcasted across the network. The neighbouring vehicles are dependent on the message transmitted by the nodes. Therefore a valid secured infrastructure is required to authenticate the messages sent in the network [1].

Without security the network is open for attacks like suppression of messages, faulty message propagation etc. Messages related to the safety of vehicles are safety-related messages and an announcement scheme is followed by the vehicle for generating and broadcasting these messages. Therefore, proper authentication of messages is required in the infrastructure to build belief about the sending node. Various cryptographic techniques are used for proving the authentication of the messages. Even then, only if the vehicles are reliable, the messages benefit the receiving nodes. If the sending vehicle is reliable, then so is the message too. The consequences of an unreliable message is very high. These unreliable messages may be generated by a faulty sensor in the vehicle or may even be generated intentionally too. Therefore, any message generated by the vehicle should be evaluated for its reliability [2].

In general, all the participating vehicles do not have a major trust on the vehicles from which it receives the message. Therefore, when a message is received, the level to which the message can be depended upon is a serious issue and it becomes mandatory for a Reputation System so that the communication becomes very much trustworthy.

A Reputation system aids in building a trust value for every vehicle in the network. These values help the other vehicle to determine which vehicles can be relied on Resnicke Zeckhauser [3] defines the operational objective of a Reputation systems as (a) To provide information that helps in distinguishing a reliable and unreliable vehicle (b) To encourage vehicles’ to behave in a trustworthy way (c) To discourage suspected vehicles from not participating in this system.

Initially, the reputation of any vehicle is void. When the vehicle starts transmitting warnings and when other vehicles finds it valid, the reputation value increases if other vehicles finds it valid. Reputation of a vehicle is the measure of belief which other vehicles have about the sender based on the reliability of earlier sent messages [4]. Usually, the belief is represented as a numerical value. With time, the participating vehicles rate the vehicle with a score. As the vehicle becomes reliable among the neighbours, it scores a positive feedback and a positive value, else and the score earned decreases.

2 Related Work

The reliability of the transmitted messages is based on the validity of the messages that have been transmitted by the vehicle. Various schemes have been proposed to implement security, reliability, authentication of messages in VANETs. Digital signatures [5] provide integrity and authentication of the transmitted messages. The Threshold method [6] verifies if same message is received from a “n” no of vehicles, but consumes a long time to check for the message validity. Network modelling [7] allows detection and correction of malicious nodes in the vehicle. But possessing the knowledge of all participating vehicles is highly infeasible and unpractical and imposes storage constraints. Decentralised infrastructure reputation based models have been proposed, but does not guarantee Robustness. In [8], Opinion piggybacking, the Vehicle appends its opinion to the already received opinions, but does not explore on the Computational burden on the vehicles like Initialisation and updating of scores. In [9], Vehicle behaviour analysis is proposed, but has a limitation that the neighboring vehicles arein a position to react immediately. A simple, practical model of a Reputation system based announcement scheme has been proposed in [10] which analyses a secure and efficient announcement scheme. A method to improve the reception rates of the messages has been proposed in [11], which uses an adaptive broadcast protocol. In order to increase the level of reliability for safety applicatons in Vanet’s, a sublayer has been suggested in [12].

3 Proposed System

In order to scale the Reputation System to a very large area, thereby benefitting many vehicles, we propose to design and analyse a Reputation system for Vanet’s. The proposed system analyses the drawbacks of the earlier approaches as below:

  1. 1.

    The existing Centralised infrastructure can be utilised to a greater extent in designing and establishing a reputation system.

  2. 2.

    The Reputation system evaluates and disseminates the reliability score of the vehicle which assists the other vehicles in the network.

  3. 3.

    Broadcasted messages are transmitted to the vehicles are received by the vehicles in a small area. A large number of vehicles can benefit if the technique can be extended to a greater area. A Centralised Reputation Server which collectively groups the scores from certain number of Regional Reputation Servers, extends the service to a larger area.

  4. 4.

    Reputation scores help the vehicle to decide on either accepting the message or not. The score earned by the vehicle indicates the level to which the vehicle had involved in reliable transmission.

4 Network Modelling and Simulation

4.1 System Components

In order to develop a Centralised Reputation System, a three Tier architecture is proposed as shown in the Fig. 1, comprising of the following components:

Fig. 1
figure 1

3-Tier architure

  1. a.

    Centralised Reputation Server (CRS): The Centralised Reputation Server is the topmost entity in the hierarchy. The CRS covers a large area and controls a certain number of RSU’s. In this model, CRS is the trusted authority. The CRS aggregates the scores received from various Regional Reputation Servers and calculates the score for a period of time. These scores can further be sent to the reputation servers on a query.

  2. b.

    Regional Reputation Server (RRS): Admission and revocation of the vehicles are monitored by the Regional Reputation Server. The RRS plays the role of receiving the scores from other neighbours, aggregating them and sends them to the CRS.

  3. c.

    Access Points (AP): Wireless communication devices facilitate connection between the Reputation Server and the vehicles. These access points can be installed in frequently visited points. The number of access points is decided on the area to be covered.

  4. d.

    Vehicle (V): Vehicles broadcast and receive messages from their neighbours. On experiencing the road related messages, the vehicles compose a feedback and sends to its Regional Reputation Server.

4.2 System Settings and Simulation

The basic assumptions for the design, the components of the Network, the algorithmic components and the operation of the system are discussed in detail. The Network model is simulated in Ns-2 with the following assumptions.

  1. (i)

    Assumptions:

    1. a.

      Vehicles move at random speeds on the roads.

    2. b.

      Traffic jam and other road conditions are simulated to occur randomly, lasting for few seconds.

    3. c.

      Vehicles are comparatively closer to the occurring event.

    4. d.

      Any message received is evaluated for reliability based on a reputation threshold parameter and a time discount function.

    5. e.

      When the receiving vehicle is experiencing the event that was informed earlier, the vehicle reports to the reputation server and it is assumed that all such experiences are reported immediately.

    6. f.

      Assuming that all the vehicles are within the communication range, the latest reputation certificates are received and reports are sent without delay.

    7. g.

      When a feedback is received for a vehicle, the existing reputation score is further updated and stored. Based on the new score, the certificate is generated accordingly.

    8. h.

      It is assumed that the vehicles in the network do not have any earlier trust built among them.

    9. i.

      It is assumed that all the vehicles, Servers, RSU’s have a synchronised clock settings.

  2. (ii)

    Algorithmic components

    The algorithm uses the following components:

    1. a.

      Aggr—an aggregation algorithm, that calculates the feedback obtained by the vehicle. The Reputation score is computed based on the feedback obtained.

    2. b.

      Time Discount (TD)- Time discount function—When a score is received, it need not be accepted as such, because with time, the score might have either increased or decreased after this received value. Therfore, a time discount fuction can be used. Based on the time when the score is received, the reputation value is offset by multiplying score with some value in the range of [0,1] to discount the reputation value.

    3. c.

      Digital Signature Schemes: Message integrity can be verified using Digital Signatures. Here, two schemes namely DS 1 , DS 2 such that DS 1  = (KG 1 , Sign 1 , Verify 1 ), DS 2  = (KG 2 , Sign 2 , Verify 2 ) can be used.

    4. d.

      Hash Function H, Message authentication Code algorithm, MAC

    5. e.

      Three configurable parameters \(Th_{rs} ,Th_{t} ,Th_{cert}\) and T such that

      1. i.

        Th rs —a threshold value to determine whether another vehicle is reputable, usually a value between 0 and 1.

      2. ii.

        Th time —a threshold used to determine whether a message tuple is sufficiently fresh for feedback reporting.

      3. iii.

        T— a large time interval during which the vehicles report feedback.

      4. iv.

        Th cert—time period for which the certificate is valid.

5 Initialisation of the System Components

5.1 Initialisation of the Centralised Reputation Server

The Centralised Reputation Server (CRS) is initialised with a set of public and private key pairs that are to be assigned for the Regional Reputation Servers. The CRS is geographically placed such that it covers a set of RRS covering a larger area. This enables the reputation scores of a smaller area to be aggregated by the CRS and then transmitted to a larger number of vehicles. Any RRS that registers with the CRS receives a pair of keys for further communication. The three tier architecture is as shown in Fig. 1.

  1. i.

    The CRS receives the aggregated reputation scores that are collected by the RRS at specific intervals.

  2. ii.

    The scores are then segregated and stored as per the identity of the vehicles.

  3. iii.

    The feedback ratings are the calculated for the individual vehicles and using continuous feedback rating algorithm, the ratings are prepared and stored locally.

  4. iv.

    Any RRS can further enquire the CRS for obtaining the scores of the vehicles that are not within the range.

5.2 Initialisation of the Regional Reputation Server (RRS)

The Regional Reputation Server is initialized as follows:

  1. i.

    The Regional Reputation Server registers itself with the Centralised Reputation server using a public, private key pair \(\left( {PU_{RRS1} ,PR_{RRS1} } \right) .\)

  2. ii.

    The RRS receives the scores from all the vehicles within its range and creates a local database for storing the details of the vehicles, such as the vehicle’s identity, Public Key, MAC Key, current reputation score of the vehicle and a feedback value.

  3. iii.

    The reputation score of a vehicle is aggregated using the algorithm Aggr.

5.3 Installation of the Access Points

The access point are installed in the system to facilitate a communication between the Vehicles and the RRS for which a communication channel needs to be established.

6 Operation of the Reputation System

The CRS, RRS, access Points and the vehicles are initialised and installed with certain algorithms for their operation some of the basic terminologies used in here are as below:

Notation

Purpose

Aggr

Reputation aggregation algorithm

MAC

Message authentication code algorithm

KG 1 , KG 2

Key generation algorithm

DS 1 , DS 2

Digital signature schemes

TD

Time discount function

Verify 1 , Verify 2

Verification algorithms

Th rs

Reputation threshold (range 0–1)

Th time

Threshold to determine the freshness of a message

Th cert

Certificate validity time

\(id_{{V_{1} }} ,id_{{V_{2} }}\)

Identity of the vehicles

\((pu_{{V_{1} }} ,pk_{{V_{1} }} ),(pu_{{V_{2} }} pk_{{V_{2} }} )\)

Public private key pair of vehicles

(PU RRS1PR RRS1)

Public private key pair of regional reputation server

t 1

Certificate generation time

t 2

Message broadcast time

t 3

Message reception time

\(rs_{{V_{1} }} ,\)

Reputation score of vehicle V1

H(m).

Hash of the message “m”

F r

Feedback Rating in the range {0, 1}

\(mk_{{V_{1} }} ,mk_{{V_{2} }}\)

MAC Key of the vehicles V1 and V2

t RRS

Time when the consolidated score is sent by RRS to CRS

Once the System components have been installed, the stage wise process by which the CRS, RRS and the vehicles work collaboratively to establish and maintain a Reputation System is as below.

6.1 Vehicle Registration and Requisition for Reputation Certificate

The registered vehicle requests for its Reputation Certificate from the Regional Reputation Server as below:

  1. i.

    The vehicle sends its identity \(id_{{V_{1} }}\) to the RRS.

  2. ii.

    On receiving a request the RRS creates a new record in the database for the requesting vehicle with the identity \(id_{{V_{1} }}\).

  3. iii.

    If the requesting vehicle had earlier registered with the RRS, then the Certificate can be retrieved locally. Otherwise, the request for the Certificate is sent to CRS. The query for the vehicle id V1 is then sent as \(Q = ((id_{{V_{{_{1} }} }} )_{{pr_{{RRS_{1} }} }} )_{{pu_{CRS} }}\) and receives a reply as \(R = ((id_{{V_{1} }} ,rs_{{V_{1} }} )_{{pu_{{RRS_{1} }} }} )_{{pr_{CRS} }}\) from which the Certificate can be generated. The Certificate, C for the requesting vehicle is then generated as \(C = \, (id_{{V_{1} }} ,pu_{{V_{1} }} ,t_{1} ,rs_{{V_{1} }} ,\alpha ),\) which holds the identity of the vehicle \(id_{{V_{1} }}\), the public key of the vehicle \(pu_{{V_{1} }}\) the time t 1, when the certificate was generated and the reputation score of the vehicle as \(rs_{{V_{1} }} ,\) which it has earned at time t 1. Here, α is Digital Signature using the algorithm Sign 1 such that

    $$\alpha = Sign_{1} \left( {id_{{V_{1} }} ,pk_{{V_{1} }} ,t_{1} ,rs_{{V_{1} }} } \right)_{{pr_{RRS1} .}}$$
  4. iv.

    The Certificate is then sent to the requesting vehicle, which is further stored by the vehicle locally. The Certificate remains valid for the defined time interval, Th cert .

6.2 Road-Related Warnings Generated and Broadcasted by the Vehicle

On obtaining the certificate C from the RRS, the vehicle now generates the message and broadcasts to its neighbours.

  1. i.

    A message “m” could be any information composed by the driver or generated from the sensors of the vehicle. The Hash of this message is calculated as H(m).

  2. ii.

    At the receiving time t 2, a time stamped Signature is generated by the Vehicle as Θ, which is \(\varTheta = Sign_{2} \left( {t_{2} ,H\left( m \right)} \right)_{{pr_{{V_{1}}}}}.\)

The vehicle composes the message M = (mt 2ΘC) and broadcasts to all the nodes in the network.

6.3 Reliability of the Message is Evaluated

When a vehicle V 2 receives the message M = (mt 2ΘC) from the sender at time t 3, the message is retrieved as below:

  1. i.

    V 2 checks if the reputation score is acceptable i.e., \(rs_{{V_{1} }} .TD \, \left( {t_{2} {-}t_{1} } \right) \ge Th_{rs}.\)

  2. ii.

    Checks if the message received is also fresh, \(t_{3} {-} \, t_{2} \le Th_{t} .\)

  3. iii.

    The verification algorithm Verify 1 is used to check if α ∊ C by using the public key of the reputation Server PU RRS .

  4. iv.

    A check on the validity of the message received by V 2 is performed using the verification algorithm Verify 2 and the public key of the Vehicle, \(pu_{{V_{1} }}\), that is extracted from the certificate C.

  5. v.

    Once the validity of the message is verified, the vehicle from which the message was received is considered reliable. The message “m” is therefore considered and a feedback is computed for the vehicle. This feedback is further stored for future reporting. If the vehicle is not a reputable one, then further messages from the vehicle is not considered.

6.4 Generation and Reporting of Feedback

On receiving the message m at the time t 3, the vehicle stores the message and waits to experience the warning received. Once the vehicle V 2 experiences the event that was described by m, the reliability of the message received can be justified. If the vehicle V 2 wishes to participate in reporting the feedback about the vehicle to the RRS, then the feedback is generated, which may be either 1 (if true) or 0 (if false) and is calculated as below:

  1. i.

    V 2 generates a feedback F r  ∊ {0, 1}, where 1 indicates a reliable message and 0 indicates an unreliable message.

  2. ii.

    V 2 submits \((id_{{V_{2} }} ,id_{{V_{1} }} ,F_{r} ,t_{2} ,t_{3} ,H\left( m \right),\varTheta )\) to the trusted hardware.

  3. iii.

    The trusted hardware computes the Message Authentication Code “D” from t 2, Θ and its MAC key \(mk_{{V_{2} }}\) as \(D = \, MAC(id_{{V_{1} }} ,id_{{V_{2} }} ,F_{r} ,t_{3} ,t_{2} ,H\left( m \right),\varTheta )_{{mk_{{V_{2} }} }}.\)

  4. iv.

    V 2 generates the feedback tuple F as \(F = \, (id_{{V_{1} }} ,id_{{V_{2} }} ,F_{r} ,t_{3} ,t_{2} ,H\left( m \right),\varTheta ,D)\). If the value of F r is 1, it is a positive feedback else if its value is 0, it is a negative feedback.

6.5 Aggregation of Reputation Score at the RRS

The RRS checks the following:

  1. i.

    RRS receives the feedback score from the set of registered vehicles.

  2. ii.

    RRS performs the set of following tasks

    1. a.

      whether \(t_{3} {-} \, t_{2} \leq Th_{time}.\)

    2. b.

      calculates D by calculating MAC from the tuple (id V1id V2f r t 2t 3H(m), Θ) using \(mk_{{V_{2} }}.\)

    3. c.

      checks if Θ is valid, using the algorithm Verify 2 and \(pr_{{V_{2} }}.\)

  3. iii.

    For a vehicle with id V , the scores received by the vehicle for a time period say “t start ” to “t end ” are aggregated. If any of the above check fails, then the message F is discarded.

  4. iv.

    For a vehicle with id V , the scores received by the vehicle for a time period say “t start ” to “t end ” are aggregated. If any of the above check fails, then the message F is discarded.

  5. v.

    The RRS applies the Aggregation algorithm “Aggr” for a specific Vehicle V x on all the received feedback messages and replaces the new score with the already available score \(rs_{{V_{1} }}.\)

  6. vi.

    This aggregated Reputation score “S” is further composed into messages and sent to the CRS, at time t RRS .

    $$S = \left( {id_{{V_{1} }} ,rs_{{V_{1} }} ,t_{RRS1} ,Th_{cert} } \right)pr_{{_{RRS1} }}$$

6.6 Reputation Aggregation Algorithm

  1. i.

    For a specific vehicle V, the algorithm selects all the feedback that have been reported from the start time t start until the present time t end , from the available database in the RRS, as:

    $$S = \left\{ {F:\left( {id_{{V_{1} }} = id_{V} } \right) \, \& \left( { \, t_{start} < t_{3} <_{ } t_{end} } \right)} \right\}$$
  2. ii.

    Multiple Feedbacks reported for a vehicle is then aggregated into a single value, by averaging and denoted as \(\hbox{``}r_{{V_{i} }} \hbox{''}.\)

6.7 Vehicle Revocation

A belief parameter r belief is configured for a node, (say) 70 %. The vehicle should have earned at least 70 % scoring. For a set of (say), 10 transmissions, the vehicle should have earned a reputation score of value “1”, at least for 7 transmissions. If a vehicle does not satisfy this constraint, it cannot be issued a Reputation Certificate for further communication.

7 Network Simulation

The Simulation is performed using Ns-2 with the parameters as shown in Table 1. The configurable parameters \(Th_{rs} , \, Th_{t} ,Th_{cert}\) and T are set as 0.7, 30 min, 30 min and 10 min respectively. These minimal values helps to visualise the effect of these parameters within the simulation time.

Table 1 Simulation parameters

Three Regions with quite a geographical distance between them is considered for this simulation. Vehicles with ID’s 1, 2, 3, 4, 5, 11 are configured under region 1, Vehicles with IDs’ 6, 7, 8, 9, 10, 12 under Region 2 and ID’s 13, 14, 15, 16, 17, 18, 19, 20 in Region 3. The three locally configured RRS’s collect the scores from the vehicles within their geographical domain, aggregate them and further send the scores to the Centralised Reputation Server. The Centralised Reputation Server accumulates all the scores and stores these values for further queries. Any RRS can query the CRS to obtain the scores for a far away Vehicle. For instance, when RRS1 queries the CRS for the score of Vehicle with ID 11, that does not belong to its geographical domain, the value so far aggregated for the vehicle is sent by the CRS. Thus the reputation of the vehicle earned so far can be distributed to vehicles in Larger area. The reputation scores that are aggregated at the Regional level, RR1, RR2, RR3 and RR4 are as shown in Tables 25 respectively.

Table 2 Reputation scores of the vehicles in region 1 stored at RRS1
Table 3 Reputation scores at RRS2
Table 4 Reputation scores at RRS3
Table 5 Aggregated scores at CRS at time t9

The CRS identifies the minimum and maximum scores obtained by the Vehicles. When the vehicles decides the next forwarding vehicle based on the reputation score it had earned, there is a considerable better performance and the throughput is found to increase as in Fig. 2. The Centralised scores earned by the vehicle aids in efficient forwarding of the packets thus aiming a better performing network.

Fig. 2
figure 2

Better throughput obtained when vehicles use Reputation Scores

Compared to the previous schemes, the time taken by the vehicles in the current scheme to update the scores has been comparatively reduced as shown in Fig. 3.

Fig. 3
figure 3

Less time consumption to update the scores

Therefore, as in Fig. 2, the throughput is found to increase and Fig. 3 shows reduction in time to send the packets in the 3-Tier architecture. Therefore, it can be seen that the proposed 3-Tier Centralised architecture for Reputation Systems, exhibit a better performance.

8 Conclusion and Future Work

The message reliability can thus be achieved by establishing a secured Centralised Reputation system. The system can be established to serve a large number of vehicles spanning to a large geographical area. Compared to the earlier schemes, this 3-Tier architecture, the messages shared and the scores earned can be utilized by the vehciles in a much gretaer area. In this paper, we have analysed the possibilty of implementing a Centralised Reputation System for VANETs’ and it has also been analysed that the message drop rate is minimised and the reputation scores are at a higher value than the earlier scheme. In future, the discrete ratings can be converted to Contiuous ratings and privacy protection schemes may be incorporated into the architecture for security.