Our paper “Securing ARP from the Ground Up” has been accepted as a short paper by CODASPY15, which will be in San Antonio, TX from March 2nd to 4th. In this post, we will talk about our solution to ARP security issues, which is called arpsec. For details, please refer to the paper below. Have fun~
0. Paper “Securing ARP from the Ground Up“
1. Threat model
In this paper, we are trying to provide a defense solution against the well-known ARP spoofing attacks (also known as ARP cache poisoning attacks), where the adversary injects the malicious MAC address bound with certain IP address into victim’s ARP cache. For example, when the MAC address injected belongs to the adversary while the IP address bound with is the real online banking system, there is a great chance that the adversary is trying to steal the your financial information by impersonating the online banking system. This could be case for online phishing. When the MAC address injected belongs to certain target and the IP address is Google, then all IP traffic of Google searching happened in the victim’s machine will be redirected to the target. This could be the case for MitM or DoS/DDoS.
2. Root cause analysis and Solutions
The root cause of ARP spoofing attacks is the result of the original ARP design, which ignored the security consideration, simply said, no authentication or authorization. Modern solutions, such as S-ARP and TARP, apply crypto components to the ARP protocol, either symmetric or asymmetric, to enforce the missing authentication and authorization. There is only one problem besides the performance degradation. No one would like to change the ARP protocol. It is what it is.
While we should NOT change the ARP protocol, we also have concerns about the secure storage for private keys used by the crypto system. A even more practical question would be shall we trust the ARP message if we know that the message originator has been compromised? Our answer to these concerns and questions is arpsec.
arpsec has been implemented on Linux with kernel 3.2. Within the kernel space, we hacked into the ARP layer to relay all ARP/RARP message to the user space, where a arpsec daemon (arpsecd) passes these messages to the logic layer and TPM layer accordingly. The logic layer is a Prolog prover used to verify the ARP message. Once it fails, the TPM layer starts a TPM attestation, challenging the remote machine by asking for the system integrity measurement. Once confirmed, the arpsecd triggers the kernel ARP cache operations to act accordingly.
The first cool part of arpsec is its logic prover, which is used to verify the ARP message. The logic behind the prover is pretty simple and the logic prover is actually slow comparing to non-logic implementations. The power of logic prover is that it provides us the confidence/ability to say we are doing what we said. Please do not underestimate this capability. Think about the our daily C/C++ or Java programming. If we were doing what we said, then there would be no bugs. Even though the logic prover we are using here is far away from a formal proof of an implementation, it is still more reliable than a non-logic implementation, because we are using logic rules rather than imperative and OO programming.
The second cool part of arpsec is its integration with TPM. Trusted Computing has been there for years but the applications are still few. This is partially because of the speed of TPM chip. However, with the help of TPM, we do not have to trust the OS as before (for sure, we have to trust all the hardwares, unfortunately). Using the TPM attestation, we can have the software-tamper-proof system integrity measurement of the remote machine without caring about the OS running on that machine, whether it is compromised (and we will know) or not.
We are looking forward to more logic component within the normal software implementation, more TPM usage either from the user space or the kernel space and more networking protocols leveraging the power of TPM, such as DNS and BGP.