Efficient Implementation on Low-Cost SoC-FPGAs of TLSv1.2 Protocol with ECC_AES Support for Secure IoT Coordinators

Security management for IoT applications is a critical research field, especially when taking into account the performance variation over the very different IoT devices. In this paper, we present high-performance client/server coordinators on low-cost SoC-FPGA devices for secure IoT data collection. Security is ensured by using the Transport Layer Security (TLS) protocol based on the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 cipher suite. The hardware architecture of the proposed coordinators is based on SW/HW co-design, implementing within the hardware accelerator core Elliptic Curve Scalar Multiplication (ECSM), which is the core operation of Elliptic Curve Cryptosystems (ECC). Meanwhile, the control of the overall TLS scheme is performed in software by an ARM Cortex-A9 microprocessor. In fact, the implementation of the ECC accelerator core around an ARM microprocessor allows not only the improvement of ECSM execution but also the performance enhancement of the overall cryptosystem. The integration of the ARM processor enables to exploit the possibility of embedded Linux features for high system flexibility. As a result, the proposed ECC accelerator requires limited area, with only 3395 LUTs on the Zynq device used to perform high-speed, 233-bit ECSMs in 413 µs, with a 50 MHz clock. Moreover, the generation of a 384-bit TLS handshake secret key between client and server coordinators requires 67.5 ms on a low cost Zynq 7Z007S device

Implementation of an FPGA based accelerator for virtual private networks.

Cheung Yu Hoi Ocean.Thesis (M.Phil.)--Chinese University of Hong Kong, 2002.Includes bibliographical references (leaves 65-70).Abstracts in English and Chinese.Chapter 1 --- Introduction --- p.1Chapter 1.1 --- Motivation --- p.1Chapter 1.2 --- Aims --- p.2Chapter 1.3 --- Contributions --- p.3Chapter 1.4 --- Thesis Outline --- p.3Chapter 2 --- Virtual Private Network and FreeS/WAN --- p.4Chapter 2.1 --- Introduction --- p.4Chapter 2.2 --- Internet Protocol Security (IPSec) --- p.4Chapter 2.3 --- Secure Virtual Private Network --- p.6Chapter 2.4 --- LibDES --- p.9Chapter 2.5 --- FreeS/WAN --- p.9Chapter 2.6 --- Commercial VPN solutions --- p.9Chapter 2.7 --- Summary --- p.11Chapter 3 --- Cryptography and Field-Programmable Gate Arrays (FPGAs) --- p.12Chapter 3.1 --- Introduction --- p.12Chapter 3.2 --- The Data Encryption Standard Algorithm (DES) --- p.12Chapter 3.2.1 --- The Triple-DES Algorithm (3DES) --- p.14Chapter 3.2.2 --- Previous work on DES and Triple-DES --- p.16Chapter 3.3 --- The IDEA Algorithm --- p.17Chapter 3.3.1 --- Multiplication Modulo 2n + 1 --- p.20Chapter 3.3.2 --- Previous work on IDEA --- p.21Chapter 3.4 --- Block Cipher Modes of operation --- p.23Chapter 3.4.1 --- Electronic Code Book (ECB) mode --- p.23Chapter 3.4.2 --- Cipher-block Chaining (CBC) mode --- p.25Chapter 3.5 --- Field-Programmable Gate Arrays --- p.27Chapter 3.5.1 --- Xilinx Virtex-E´ёØ FPGA --- p.27Chapter 3.6 --- Pilchard --- p.30Chapter 3.6.1 --- Memory Cache Control Mode --- p.31Chapter 3.7 --- Electronic Design Automation Tools --- p.32Chapter 3.8 --- Summary --- p.33Chapter 4 --- ImplementationChapter 4.1 --- Introduction --- p.36Chapter 4.1.1 --- Hardware Platform --- p.36Chapter 4.1.2 --- Reconfigurable Hardware Computing Environment --- p.36Chapter 4.1.3 --- Pilchard Software --- p.38Chapter 4.2 --- DES in ECB mode --- p.39Chapter 4.2.1 --- Hardware --- p.39Chapter 4.2.2 --- Software Interface --- p.40Chapter 4.3 --- DES in CBC mode --- p.42Chapter 4.3.1 --- Hardware --- p.42Chapter 4.3.2 --- Software Interface --- p.42Chapter 4.4 --- Triple-DES in CBC mode --- p.45Chapter 4.4.1 --- Hardware --- p.45Chapter 4.4.2 --- Software Interface --- p.45Chapter 4.5 --- IDEA in ECB mode --- p.48Chapter 4.5.1 --- Multiplication Modulo 216 + 1 --- p.48Chapter 4.5.2 --- Hardware --- p.48Chapter 4.5.3 --- Software Interface --- p.50Chapter 4.6 --- Triple-DES accelerator in LibDES --- p.51Chapter 4.7 --- Triple-DES accelerator in FreeS/WAN --- p.52Chapter 4.8 --- IDEA accelerator in FreeS/WAN --- p.53Chapter 4.9 --- Summary --- p.54Chapter 5 --- Results --- p.55Chapter 5.1 --- Introduction --- p.55Chapter 5.2 --- Benchmarking environment --- p.55Chapter 5.3 --- Performance of Triple-DES and IDEA accelerator --- p.56Chapter 5.3.1 --- Performance of Triple-DES core --- p.55Chapter 5.3.2 --- Performance of IDEA core --- p.58Chapter 5.4 --- Benchmark of FreeSAVAN --- p.59Chapter 5.4.1 --- Triple-DES --- p.59Chapter 5.4.2 --- IDEA --- p.60Chapter 5.5 --- Summary --- p.61Chapter 6 --- Conclusion --- p.62Chapter 6.1 --- Future development --- p.63Bibliography --- p.6

On the Edge of Secure Connectivity via Software-Defined Networking

Securing communication in computer networks has been an essential feature ever since the Internet, as we know it today, was started. One of the best known and most common methods for secure communication is to use a Virtual Private Network (VPN) solution, mainly operating with an IP security (IPsec) protocol suite originally published in 1995 (RFC1825). It is clear that the Internet, and networks in general, have changed dramatically since then. In particular, the onset of the Cloud and the Internet-of-Things (IoT) have placed new demands on secure networking. Even though the IPsec suite has been updated over the years, it is starting to reach the limits of its capabilities in its present form. Recent advances in networking have thrown up Software-Defined Networking (SDN), which decouples the control and data planes, and thus centralizes the network control. SDN provides arbitrary network topologies and elastic packet forwarding that have enabled useful innovations at the network level. This thesis studies SDN-powered VPN networking and explains the benefits of this combination. Even though the main context is the Cloud, the approaches described here are also valid for non-Cloud operation and are thus suitable for a variety of other use cases for both SMEs and large corporations. In addition to IPsec, open source TLS-based VPN (e.g. OpenVPN) solutions are often used to establish secure tunnels. Research shows that a full-mesh VPN network between multiple sites can be provided using OpenVPN and it can be utilized by SDN to create a seamless, resilient layer-2 overlay for multiple purposes, including the Cloud. However, such a VPN tunnel suffers from resiliency problems and cannot meet the increasing availability requirements. The network setup proposed here is similar to Software-Defined WAN (SD-WAN) solutions and is extremely useful for applications with strict requirements for resiliency and security, even if best-effort ISP is used. IPsec is still preferred over OpenVPN for some use cases, especially by smaller enterprises. Therefore, this research also examines the possibilities for high availability, load balancing, and faster operational speeds for IPsec. We present a novel approach involving the separation of the Internet Key Exchange (IKE) and the Encapsulation Security Payload (ESP) in SDN fashion to operate from separate devices. This allows central management for the IKE while several separate ESP devices can concentrate on the heavy processing. Initially, our research relied on software solutions for ESP processing. Despite the ingenuity of the architectural concept, and although it provided high availability and good load balancing, there was no anti-replay protection. Since anti-replay protection is vital for secure communication, another approach was required. It thus became clear that the ideal solution for such large IPsec tunneling would be to have a pool of fast ESP devices, but to confine the IKE operation to a single centralized device. This would obviate the need for load balancing but still allow high availability via the device pool. The focus of this research thus turned to the study of pure hardware solutions on an FPGA, and their feasibility and production readiness for application in the Cloud context. Our research shows that FPGA works fluently in an SDN network as a standalone IPsec accelerator for ESP packets. The proposed architecture has 10 Gbps throughput, yet the latency is less than 10 µs, meaning that this architecture is especially efficient for data center use and offers increased performance and latency requirements. The high demands of the network packet processing can be met using several different approaches, so this approach is not just limited to the topics presented in this thesis. Global network traffic is growing all the time, so the development of more efficient methods and devices is inevitable. The increasing number of IoT devices will result in a lot of network traffic utilising the Cloud infrastructures in the near future. Based on the latest research, once SDN and hardware acceleration have become fully integrated into the Cloud, the future for secure networking looks promising. SDN technology will open up a wide range of new possibilities for data forwarding, while hardware acceleration will satisfy the increased performance requirements. Although it still remains to be seen whether SDN can answer all the requirements for performance, high availability and resiliency, this thesis shows that it is a very competent technology, even though we have explored only a minor fraction of its capabilities

A High-Throughput Hardware Implementation of NAT Traversal For IPSEC VPN

In this paper, we present a high-throughput FPGA implementation of IPSec core. The core supports both NAT and non-NAT mode and can be used in high speed security gateway devices. Although IPSec ESP is very computing intensive for its cryptography process, our implementation shows that it can achieve high throughput and low lantency. The system is realized on the Zynq XC7Z045 from Xilinx and was verified and tested in practice. Results show that the design can gives a peak throughput of 5.721 Gbps for the IPSec ESP tunnel mode in NAT mode and 7.753 Gbps in non-NAT mode using one single AES encrypt core. We also compare the performance of the core when running in other mode of encryption

Separation of SSL protocol phases across process boundaries

Secure Sockets Layer is the de-facto standard used in the industry today for secure communications through web sites. An SSL connection is established by performing a Handshake, which is followed by the Record phase. While the SSL Handshake is computationally intensive and can cause of bottlenecks on an application server, the Record phase can cause similar bottlenecks while encrypting large volumes of data. SSL Accelerators have been used to improve the performance of SSL-based application servers. These devices are expensive, complex to configure and inflexible to customizations. By separating the SSL Handshake and the Record phases into separate software processes, high availability and throughput can be achieved using open-source software and platforms. The delegation of the SSL Record phase to a separate process by transfer of necessary cryptographic information was achieved. Load tests conducted, showed gains with the separation of the Handshake and Record phases at nominal data sizes and the approach provides flexibility for enhancements to be carried out for performance improvements at higher data sizes

An Architecture for QoS-capable Integrated Security Gateway to Protect Avionic Data Network

International audienceWhile the use of Internet Protocol (IP) in aviation allows new applications and benefits, it opens the doors for security risks and attacks. Many security mechanisms and solutions have evolved to mitigate the ever continuously increasing number of network attacks. Although these conventional solutions have solved some security problems, they also leave some security holes. Securing open and complex systems have become more and more complicated and obviously, the dependence on a single security mechanism gives a false sense of security while opening the doors for attackers. Hence, to ensure secure networks, several security mechanisms must work together in a harmonic multi-layered way. In addition, if we take QoS requirements into account, the problem becomes more complicated and necessitates in-depth reflexions. In this paper, we present the architecture of our QoS-capable integrated security gateway: a gateway that highly integrates well chosen technologies in the area of network security as well as QoS mechanisms to provide the strongest level of security for avionic data network; our main aim is to provide both multi-layered security and stable performances for critical network applications

GNFC: Towards Network Function Cloudification

An increasing demand is seen from enterprises to host and dynamically manage middlebox services in public clouds in order to leverage the same benefits that network functions provide in traditional, in-house deployments. However, today's public clouds provide only a limited view and programmability for tenants that challenges flexible deployment of transparent, software-defined network functions. Moreover, current virtual network functions can't take full advantage of a virtualized cloud environment, limiting scalability and fault tolerance. In this paper we review and evaluate the current infrastructural limitations imposed by public cloud providers and present the design and implementation of GNFC, a cloud-based Network Function Virtualization (NFV) framework that gives tenants the ability to transparently attach stateless, container-based network functions to their services hosted in public clouds. We evaluate the proposed system over three public cloud providers (Amazon EC2, Microsoft Azure and Google Compute Engine) and show the effects on end-to-end latency and throughput using various instance types for NFV hosts

Implications and Limitations of Securing an InfiniBand Network

The InfiniBand Architecture is one of the leading network interconnects used in high performance computing, delivering very high bandwidth and low latency. As the popularity of InfiniBand increases, the possibility for new InfiniBand applications arise outside the domain of high performance computing, thereby creating the opportunity for new security risks. In this work, new security questions are considered and addressed. The study demonstrates that many common traffic analyzing tools cannot monitor or capture InfiniBand traffic transmitted between two hosts. Due to the kernel bypass nature of InfiniBand, many host-based network security systems cannot be executed on InfiniBand applications. Those that can impose a significant performance loss for the network. The research concludes that not all network security practices used for Ethernet translate to InfiniBand as previously suggested and that an answer to meeting specific security requirements for an InfiniBand network might reside in hardware offload