Utilización de la realidad aumentada en proyecto piloto

Since most of the attacks against routing control messages are built on manipulating their contents, a simple countermeasure would be to authenticate each routing control message [101]. However, several questions arise in this case, e.g., what entity should authenticate the routing control messages? Which information should be authenticated? Which entity should verify the authenticity of the routing control message? Naturally, the source node that originates the control message should enable authentication of it. In this way, immutable information is protected, but mutable information, if found, cannot be authenticated because it has not been yet added by intermediate nodes. Moreover, if we suppose that only the destination node can verify the authenticity of the control messages, then we can ensure that it will not respond to any spoofed control message. Thus, the creation of an incorrect routing state can be prevented at the destination node and at the source node using the same logic for routing replies. However, intermediate nodes can still be exposed to spoofed control messages. Therefore, the creation of an incorrect routing state is possible if they update their routing table based on the information carried by these spoofed control messages. Hence, we need an authentication mechanism that enables every node to authenticate and verify control messages processed by other nodes. In the following, we discuss examples of authentication mechanisms that provide this capability and their applicability to VANETs.

6.1.1.1 Authenticated Routing for Ad hoc Networks (ARAN)

In ARAN [100], an asymmetric cryptography scheme is suggested to protect the routing control messages. A trusted certificate server issues a certificate to each node before starting the route discovery process. When a new route discovery process starts, the source node broadcasts a signed route discovery packet (RDP) that includes the destination identifier, its certificate, a nonce, a time stamp, and the source’s digital signature on all these contents. Each first intermediate node that receives this RDP checks the signature of the source, signs the RDP, and adds its

certificate. Therefore, the processed RDP message contains two signatures: that of the source and the signature of the intermediate node that processed it. The processing of the RDP at each successive intermediate node is carried as follows. The intermediate node validates the signatures of both the source and the last intermediate node. If the verification is successful, it removes the certificate and the signature of the last intermediate node, signs the contents of the processed RDP, appends its own certificate, and forwards this message to other nodes. The same methodology is used to unicast the reply packet (REP) back to the source node once the RDP is received by the destination node. ARAN does not use a hop-count field while performing the route discovery process, i.e., ARAN discovers the quickest routes based on the message propagation delay rather than the shortest ones in terms of hop-count.

With regard to VANETs, the authentication mechanism used in ARAN provides message authentication, message integrity, and non-repudiation. It also prevents spoofing and modification attacks against the routing control messages and replay attacks by using nonce and timestamp fields. However, this authentication mechanism does not provide protection to mutable and untraceable information in the control message, e.g., hop-count, because ARAN eliminates it and depends on the message propagation delay as we mentioned above.

6.1.1.2 Ariadne: A Secure On-demand Routing Protocol for Ad hoc Networks

Besides utilising asymmetric cryptography, Ariadne [163] proposes the use of one of the following two mechanisms to authenticate control messages: standard message authentication codes (MACs) and symmetric cryptography using broadcast authentication protocol, which is TESLA. TESLA is a broadcast authentication protocol where the sender adds a MAC keyed according to time intervals. Based on a key disclosure interval, the receiver should wait until it receives the corresponding key to verify the message. TESLA is based on loose time synchronisation between the sender and the receiver [98].

Using TESLA, the route discovery process starts in Ariadne when the source node broadcasts a routing request message that includes source and destination

identifiers, request id, time interval, and a MAC computed over these elements using a key shared between the source and the destination nodes. When an intermediate node receives this request, it verifies the time interval field value that must not be too far in the future and its corresponding key which must not have been disclosed yet. If the verification is successful, the intermediate node appends its identifier to the node list, computes a MAC over the entire request message using its current TESLA key, appends this new computed MAC to the MACs list, and forwards the resulting request message. Using the per-hop hashing technique, Ariadne prevents intermediate nodes removing other nodes from the request message. When the destination node receives this request message, it verifies the TESLA security condition, i.e., that the TESLA keys that were used have not been disclosed yet, and verifies the per-hop hash value of each intermediate node in the node list by iteratively computing all per-hop hash values. The destination then responds with a route reply message if the above verifications were successful. Each intermediate node that receives this route reply waits until it has revealed the TESLA key it used to compute the MAC for the corresponding request message. Then, it appends this TESLA key and forwards the resulting reply message to the next intermediate node. Finally, the source node receives a reply message with all the TESLA keys needed to verify the MACs of intermediate nodes and consequently, authenticate these intermediate nodes.

Obviously, using TESLA as an authentication mechanism cannot satisfy the real time constraints required by VANETs’ applications. The end-to-end delay increases because of the time-delayed key disclosure. Another drawback arises when the source node, which waits for the disclosure of TESLA keys by the intermediate nodes, becomes out of the communication range of at least one of intermediate nodes. As a result, the source cannot verify the reply message and it is discarded. This could easily happen in VANETs due to the highly dynamic nature of vehicles. Furthermore, the non-repudiation property cannot be guaranteed using symmetric cryptography, i.e., shared keys.

6.1.1.3 Secure Ad hoc On-Demand Distance Vector (SAODV)

SAODV [164] is a secure extension of the AODV routing protocol. It proposes using digital signatures to authenticate immutable information in the routing control messages and hash chains to secure the hop-count field, which is mutable and untraceable. Every node generates a routing control message that contains the following fields: HopCount set to zero, MaxHopCount set to the TTL value of the IP header, Hash, and TopHash. After that, it initialises the Hash field with a random value and calculates the TopHash by hashing that random value MaxHopCount times. The MaxHopCount and TopHash fields are immutable thus they are secured using a digital signature along with other immutable information. When an intermediate node receives the control message, it first authenticates the digital signature of immutable fields then hashes the value of Hash field (MaxHopCount – HopCount) times. If the calculated value and the TopHash fields are the same, then the HopCount is verified. In this way, adversaries cannot enforce a previous correct state due to the one-way property of hash functions. Therefore, they cannot decrease the hop-count value to make the route look shorter than it really is. However, this is not always true because the adversarial node can still pass the control message without increasing the HopCount field or updating the Hash field value. As a result, the route will look shorter than it is. Besides that, the adversary can always increase the HopCount value and disrupt the route discovery process without being detected.