Partitioned security processor architecture on FPGA platform

Abstract

Internet protocol security (IPSec), secure sockets layer (SSL)/transport layer security (TLS) and other security protocols necessitate high throughput hardware implementation of cryptographic functions. In recent literature, cryptographic functions implemented in software, application specific integrated circuit (ASIC) and field programmable gate array (FPGA). They are not necessarily optimized for throughput. Due to the various side-channel based attacks on cache and memory, and various malware based exfiltration of security keys and other sensitive information, cryptographic enclave processors are implemented which isolates the cryptographically sensitive information like keys. We propose a partitioned enclave architecture targeting IPSec, TLS and SSL where the partitioned area ensures that the processor data-path is completely isolated from the secret-key memory. The security processor consists of a Trivium random number generator, Rivest-Shamir-Adleman (RSA), advanced encryption standard (AES) and KECCAK cryptos. We implement three different optimized KECCAK architectures. The processing element (PE) handles all communication interfaces, data paths, and control hazards of network security processor. The memory of KECCAK and AES communication is done via a direct memory access controller to reduce the PE overhead. The whole system is demonstrated by FPGA implementation using Vivado 2015.2 on Artix-7 (XC7A100T, CSG324). The performances of the implemented KECCAKs are better in terms of security, throughput and resource than the existing literature.

The Blockchain Based Auditor on Secret key Life Cycle in Reconfigurable Platform

“…The architecture with blockchain to protect severe key threats consumes 95k logic cells which is around 45% of the total logic cells available in Artix-7 FPGA. As shown in Table I articles [5], [8] and [6] proposed dedicated secret key memories which are completely isolated from processor area to prevent software threats but this architecture does not prevent incorrect use, insecure movement and non-destructions issues of keys. If any spoofing IPs or dishonest probes already exist inside the architectures of [5], [8] and [6] and try to read secret key stored in dedictaed key memory, the system will allow the key transaction to those malicious nodes.…”

“…As shown in Table I articles [5], [8] and [6] proposed dedicated secret key memories which are completely isolated from processor area to prevent software threats but this architecture does not prevent incorrect use, insecure movement and non-destructions issues of keys. If any spoofing IPs or dishonest probes already exist inside the architectures of [5], [8] and [6] and try to read secret key stored in dedictaed key memory, the system will allow the key transaction to those malicious nodes. Though the dedicated key memories proposed in these article are physically isolated but can not prevent said incorrect and insecure movement of secret keys.…”

“…In this architecture we have partitioned three areas such (i) processor area, (II) crypto area and (iii)confidential area. The whole architectural details is stated in [6]. The partitioned and isolated confidential area to store secret keys assures that the secret key never come in the processor area because the processor area is very much vulnerable for various software threats.…”

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

“…Efficient implementations of these protocols as embedded cryptosystems can be problematic, since the target devices are usually very limited in terms of power, resources and timing. Several TLS/SSL embedded cryptosystem implementations have been proposed in the literature [12][13][14][15][16][17]. OpenSSL [18,19] is the most deployed library for TLS/SSL applications through software implementations of basic cryptographic functions.…”

“…For only-software TLS/SSL implementations [17,20], servers can be overloaded with heavy cryptographic operations, which results in long response times. To alleviate this bottleneck, dedicated hardware coprocessors [12][13][14][15][16][17]21] have been proposed, as Network Security Processors (NSP), as a solution to free these severs from cryptographic operations for flexible management. Nevertheless, although effective efforts have been made [10] for the acceleration of encryption methods, NSPs can provoke an overhead of hardware resources utilization [12,16] to achieve high-performance, due to the required intensive computations within cryptographic algorithms.…”