It is time to think about your project. Please form a group of two or three students and select a computer network paper that you are interested in. The topic should about QUIC.
After selecting your paper, you should submit a one-page summary by April 15 (Only one person in the group should submit the summary). The one-page summary should include the names of students in your group, the name of the paper that you have selected, and a paragraph about the paper.
After selecting this paper, you are supposed to read the paper carefully and reproduce their experiments by using QUIC.
Analyzing and Securing SOME/IP Automotive Services with Formal and Practical Methods
Copyright By PowCoder代写 加微信 powcoder
Make sure you understand the MITM attack in the Some / IP paper to see if the QUIC can solve these problems. Try to reproduce the three experiments by using QUIC.
Our goal is to test if we use the QUIC protocol for communication, could we improve Security and Reliability (use the 3 MITM attack experiments in SOME/IP for QUIC experiments).
The dataset is nuScenes.
The deadline is May 14th, it could postpone.
You could use multipath-QUIC to do the three experiments (or you could try to do it by you own)
GitHub – qdeconinck/mp-quic: Please read https://multipath-quic.org/2017/12/09/artifacts- available.html to figure out how to setup the code.
Experiment information from the “Analyzing and Securing SOME/IP Automotive Services with Formal and Practical Methods” are below, just use it as a reference to do the three experiments.
1. Copycat Attack on the Service Offer
The general idea of the copycat attack is waiting for a regular server S to send a broadcast service offer and then immediately send a service offer but with the endpoint option of the attacker A.
Figure illustrates the attack with an example. First, the regular S sends the service offer message OfferService(0x1234, 0x5678) with Service ID 0x1234 and Instance ID 0x5678 and endpoint option Endpoint(10.0.0.2:30509). As soon as A receives this message, she sends the same service offer but with her own endpoint option Endpoint 10.0.0.4:30510. A client C would (usually) receive both service offers, since the attacker is not capable to influence lower-layer communication. C may choose A as the service provider to send his requests to. A can now forward these requests to the original server S as well as the responses from S back to C. In this MITM position, A can perform further attacks, e.g., manipulating message contents or (selectively) dropping messages.
In the Tamarin model, the presence of this attack can be shown by verifying that whenever a client receives a response from a server which contains some random data that was newly generated by the server and, thus, unknown by the attacker before the send event, the response was sent by the server to the correct client endpoint. For this lemma, Tamarin produces an attack trace that corresponds to the described attack.
In practice, the copycat attack has several problems (from the point of view of the attacker). First, a client may have already established a connection with the server and will not change to another server. Second, even if this is not the case, there is no guarantee that the client will choose the attacker as the service provider. Since the service offer of the original server is always sent before the attacker’s service offer, the client may never choose the attacker as a service provider. This approach is also in conflict with the SOME/IP specification, which demands that SOME/IP service instances are unique. Thus, this might enable the detection of the attack with an Intrusion Detection System (IDS). However, as our implementation and evaluation have shown (cf. Section 6), a regular server simply ignores such messages.
Alternatively, the attacker could use a different Instance ID. A client, who accepts other service instances, could possibly choose the attacker as before. However, there is still no guarantee that the client chooses the attacker as service instance. In addition, the attacker needs to know valid Instance IDs the client accepts (if the client does not accept all Instance IDs).
In case the load balancing options are used (cf. Section 3), the attacker may also send a service offer with the highest priority and weight option. If other instances with the same priority and weight are present, the attacker still has a chance to be chosen randomly.
2. De-association Attack on the Service Offer
To address the aforementioned issues, we extend the copycat attack by making the clients C believe that the service of the regular server S is no longer available. For this, A additionally de-associates C from S by sending a unicast StopOffer message with the regular server’s endpoint option.
Figure 3 shows an exemplary attack. S sends OfferService(0x1234, 0x5678) with Endpoint(10.0.0.2:30509). Then, A immediately sends StopOffer(0x1234, 0x5678) for Endpoint(10.0.0.2:30509) of S as unicast to C with interest in the service. As in the copycat attack, A also immediately sends her own service offer to get in the MITM position.
Tamarin generates this attack, if the lemma mentioned in the previous section is further restricted to cases where the server was known by the client a priori.
The StopOffer messages are sent to the clients as unicast, since if S would receive this, it would stop providing the service, assuming another server would take over. This would prevent A from getting into the MITM position. The OfferService message of the attacker can be sent as broadcast since S just ignores this message.
The de-association attack has the drawback that A needs to know the clients which are interested in the service. Otherwise, she could not send unicast StopOffer messages to them. Thus, the attacker needs to identify these clients. Since A can only eavesdrop on broadcast communication, she can either listen to broadcast FindService() messages of clients or other broadcast messages which identify clients and their IP addresses. Alternatively, A can simply send the StopOffer message to the entire IP range of the network (excluding the regular server).
3. Attack on Publish/Subscribe
Based on the request/response attack discovered with Tamarin, we developed an attack on publish/subscribe as shown in Figure 4. The regular server sends OfferService(0x1234, 0x5678) with Endpoint(10.0.0.2:30509). Then, C and S subscribe to the service with SubscribeEventgroup(0x1234, 0x5678) and their respective endpoint option, i.e., Endpoint(10.0.0.3:3333) for C and Endpoint(10.0.0.4:4444) for the attacker. S acknowledges this by sending SubscribeEventgroupACK(0x1234, 0x5678).
A also performs – as fast as possible – one of the presented attack on the service offer, making C believe that the attacker offers the desired service. C sends SubscribeEventgroup(0x1234, 0x5678) with Endpoint(10.0.0.4:3334) to subscribe to A. A sends StopSubscribeEventgroup(0x1234, 0x5678) with C’s endpoint option Endpoint(10.0.0.3:3333) to S for unsubscribing C and stopping S to send event messages to C. A sends the Acknowledgment SubscribeEventgroupACK(0x1234, 0x5678) to C.
C can now perform MITM attacks. When S sends event messages Event(0x1234, 0x5678) for his service, these messages are sent to the attacker and not to C. A can then decide what to do with these messages, e.g., alter them before forwarding them to the client or drop them.
6 ATTACK EVALUATION
In this section, we briefly describe our implementation of the attacks with vsomeip and CANoe as well as the evaluation.
6.1 Attack Implementation
Our first implementation consists of a client, a server offering a service, and the MITM attacker which are each implemented on an ARM1176JZF-S board running Linux Debian (Kernel 4.19) and vsomeip [7] 3.1.16.1. The three boards are connected via a switch and communicate via UDP (or TCP with similar results). We used the examples shipped with vsomeip as test cases for request/response and publish/subscribe communication. For request/response, the server offers a service for around 10 seconds and regularly sends OfferService messages (at the latest every 2.5 seconds). After 10 seconds, the server sends a StopOffer message and waits for around 10 seconds before it starts over. The client requests data around every second while the service is offered. Note that there are small variations when messages are sent depending on the load of the system and network. The publish/subscribe example starts the same way. Instead of a request, the client sends a subscribe message as soon as the service is available which is acknowledged by the server. The server then sends events every second to the subscribed client. The attacker is implemented with Scapy [6].
In our second implementation, SOME/IP client and server are implemented on a PC running CANoe 9.0.137 [11] with the SOME/IP library in combination with the VN5610 Automotive Ethernet interface.
PC and VN5610 are connected via a switch. The attacker is implemented in a Linux VM on the PC. The SOME/IP communication is implemented in the same way as in the vsomeip implementation.
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com