SDN implementation of zero-knowledge intrusion prevention system

Zero Knowledge proof (ZK proof) is a cryptographic technique that allows to prove a certain information is known without revealing it. According to its definition, it is a privacy and security upgrade since no sensitive data is either disclosed or leave the place where it is stored in. Current application scenarios are limited to secure authentication, blockchain and cryptocurrency, and in general privacy-preserving data sharing. Setting-up a ZK-proof system is a hard task due to the processes required by such system and due to the high-performance hardware requirement. In addition, a non-negligible effort is required to carefully design and implement the computation the proof is computed on (the circuit), handle intermediate data and results, and face technical aspects to practically compute such proofs. Thus, building a ZK system does not come for free, but its security and privacy properties are desirable. A new idea of application uses the non-interactivity property of ZK proofs by placing them in the context of communication networks where, to keep current running servers free from any changes, an intermediate entity, the middle-box, acts as the verifier, that is the entity that make sure the generated proof is valid. Because middle-box is placed between clients and a server, by verifying a proof the middle-box can drop or let pass packets according to the verification process result. This is an idea of a HTTP firewall implementation using ZK proofs. Beyond the concept of firewall in such a context, no practical solution was provided to distribute the three processes foreseen by ZK proofs (setup, proving and verifying) into three separate entities, but they are all placed and run into one, single system, making the solution impracticable in this scenario. Moreover, using ZK proofs should be an opportunity for clients and should not replace the traditional method where no proof is sent out. So, both two methods must be supported and thus the middle-box must be able to distinguish whether one or the other technique is used. Finally, middle box must have a way to check if the received proof has been computed on the received message the client is willing to send to server. This is a crucial issue since client must be prevented from sending a valid proof (computed on a valid message) along with an invalid message. This thesis proposes solutions to these problems and shows that a HTTPS intrusion prevention system in a communication network in the context of ZK proof can be implemented. The proving and verifying processes take place in two different systems, bringing the solution closer to a real scenario. To implement such scenario and to let both traditional traffic inspection and the new zero-knowledge based co-exist, middle-box is implemented as the couple switch – SDN controller where the proof is verified and checked whether it has been computed on the HTTP packet the client attempts to send.

Zero Knowledge proof (ZK proof) è una tecnica crittografica, la quale consente di dimostrare che si è in possesso di una certa informazione senza rivelarla. Per definizione, fornisce un upgrade in termini di privacy e sicurezza dal momento che nessun dato sensibile viene rivelato o lascia il posto in cui è memorizzato. Viene solitamente utilizzato per l’autenticazione sicura, blockchain e cryptocurrency e in generale per la condivisione sicura di dati. Implementare un sistema ZK risulta complicato a causa delle computazioni richieste da tale sistema e a causa degli elevati requisiti hardware. Inoltre, sviluppare e implementare il costrutto dal quale le prove verranno generate (ovvero il circuito), gestire dati intermedi e risultati, e affrontare aspetti tecnici per implementare praticamente questo sistema richiede uno sforzo non trascurabile, anche se la sicurezza e la privacy che garantisce sono proprietà imprescindibili. Un nuovo tipo di scenario in cui vengono impiegate le ZK proofs sfrutta la loro proprietà di non-interattività per poterle utilizzare nel contesto delle communication networks dove, al fine di non impattare i server con l’introduzione di tale sistema, un ente intermedio, il middlebox, ne effettua la verifica (tale verifica è il processo con il quale si attesta la validità di tale prova). Poiché il middlebox viene posizionato tra il client e il server, in base al risultato del processo di verifica i pacchetti vengono fatti passare o scartati. Tale soluzione può essere applicata per l’implementazione di un firewall HTTP basato sulle ZK proofs. Al di là del concetto di firewall in take contesto, nessuna soluzione pratica viene fornita per distribuire i tre processi previsti dal costrutto Zero Knowledge (setup, proving and verifying) in tre entità separate, ma vengono eseguite un un unico monolitico sistema, rendendo la soluzione infattibile per questo scenario. Inoltre, usare le ZK proofs deve essere un’opportunità aggiuntiva per i client rispetto al metodo tradizionale dove nessun supporto aggiuntivo viene inviato. Dunque, entrambi i metodi devono essere supportati e il middlebox deve essere in grado di distinguere quando una o l’altra tecnica viene utilizzata. Infine, il middlebox deve poter essere in grado di controllare che la prova ricevuta è stata effettivamente calcolata sul pacchetto dati che si vuole inviare al server. Questa funzionalità chiave evita che un client invii una prova (calcolata su un pacchetto dati valido) insieme ad un secondo pacchetto dati, potenzialmente non valido. Questa tesi propone delle soluzioni a questi problemi e mostra come un HTTPS intrution prevention system basato su ZK proof e implementato in una communication network sia possibile. Il processo di generazione e verifica delle prove avviene in due sistemi differenti, avvicinando la soluzione al caso reale. Per implementare tale scenario il middlebox è stato ulteriormente sviluppato come la coppia switch – controller SDN, in quest’ultimo dove la prova viene verificata e controllato che sia stata generata a partire dal pacchetto dati che il client vuole inviare al server (richiesta HTTPS).