A 6×m size register file is used as memory to store the initial, intermediate and final outputs of the ECC unit. It contains two 6×1 sizes of multiplexers and one 1×6 size of a demultiplexer. The intent of routing multiplexers is to read two m-bit operands. Similarly, a demultiplexer is incorporated to update the memory contents. The related control signals (not given in Fig. 2) are generated by the ECC controller.

The pink color in Fig. 2 shows the ALU that contains an adder (ADD), squarer (SQR), multiplier (MULT) and two reduction (RED) blocks (connected one after each SQR and MULT). Moreover, for routing purposes, a 3×1 multiplexer is used to select the corresponding data for writing on a storage system. Therefore, in GF(2m) field, the addition is performed by employing bitwise Exclusive-OR operations. The SQR unit in Fig. 2 is implemented by putting a ‘0’ bit after every successive data bit, as implemented in hardware accelerators of [11,13,19].

The polynomial multiplication computation specifies the performance of the PM architecture [2,11,17–19,21,27,28,30–32]. For multiplying two m-bit polynomial multiplications, several architectures have been presented in the literature [11,17–19,21,27,28,30]. These includes (i) bit-serial, (ii) bit-parallel, (iii) digit-serial and (iv) digit-parallel approaches. Moreover, some systolic polynomial multiplication designs are also described in [33–35]. In this context, the bit-serial designs are more appropriate for achieving the low-area and power-efficient architectures. But, on the other hand, the computational cost of bit-serial designs is the overhead as it utilizes m clock cycles for the multiplication of two m-bit operands. For high-speed cryptographic applications such as network servers, bit parallel and digit parallel multipliers are more attractive choices as they consume a single clock cycle for a polynomial multiplication [11,36,37]. Higher hardware resource utilization and larger power consumptions limit the use of bit and digit parallel multipliers for wireless sensor nodes and RFID applications. The digit-serial multipliers consider both area and computational cost (throughput) simultaneously for polynomial multiplication. It takes a=bc cycles for one polynomial multiplication, where a is the total digits, b is the operand length and c is digit size. Therefore, the digit-serial polynomial multipliers are the more attractive alternative for multiplying two polynomials. Consequently, our MULT contains a digit-serial architecture.

Proposed digit-serial multiplier architecture: Our proposed digit-serial polynomial multiplication architecture (24-bits) is shown with the green color in Fig. 2. The reason to select a 24-bits digit size is to obtain an optimal computational cost with minimum hardware resource utilization. The longer digit length reduces clock cycles requirement but utilizes more hardware resources and consumes more power which is not feasible for wireless sensor nodes and RFID applications [19,21]. With this compliance, we have employed a 24-bit digit size in our multiplication architecture of Fig. 2 where two m-bit polynomials, i.e., A, and B, are input to the proposed multiplier. We have stored an m-bit polynomial B in an m-bit buffer. Then, to initiate a polynomial multiplication in the first cycle, we have loaded 24-bits of polynomial B from LSB (least-significant-side) into buffer B0 for polynomial multiplications using M0 multiplier. The size of B0 is also 24-bits. In the next cycle, the next 24-bits of polynomial B are loaded into B0 for multiplication. After the second multiplication of 24-bits of polynomial B with an m-bit polynomial A, we have accumulated the current generated result with the previous result to acquire the resultant polynomial. This process will continue until all the 24-bit digits of polynomial B are multiplied with an m-bit input polynomial A. Finally, the resultant polynomial contains a 2×m−1 bit length. The computational cost of our multiplier is a=bc+1 cycles, where a is the total digits, b is the operand length (163 and 233 in this work) and c is the digit length (24-bits in this work). An additional clock cycle is needed to load an m-bit polynomial B into a buffer.

For the computation of one m-bit polynomial squaring or two m-bit polynomial multiplications, the proposed SQR and MULT units result in 2×m−1 bit polynomials length, respectively. Therefore, a reduction is needed to obtain an m-bit polynomials. The RED block in Fig. 2 is implemented using NIST defined reduction algorithms. For the corresponding reduction algorithms over GF(2163) and GF(2233), we refer readers to [6,37]. Moreover, in Algorithm 1, the reconversion from projective to affine shows that a finite field inversion operation is needed. The inversion block is not shown in Fig. 2. However, we have used an Itoh-Tsujii inversion algorithm which is initially proposed in 1988 and the corresponding mathematical formulations are completely described in [38]. For implementations, it requires frequent squaring and multiplication operations [11,13,21]. Over GF(2163) and GF(2233), the corresponding Itoh-Tsujii inversion algorithms are represented in [39,5], respectively. The Itoh-Tsujii algorithm in our design of Fig. 2 is implemented by sharing hardware resources of SQR and MULT blocks as implemented in [5,39]. This (also) allow us to save the hardware cost of our proposed design.

The ECCCNTRL unit is responsible to generate the corresponding control signals for the routing multiplexers (i.e., M(4×1) and M(3×1)) and MULT unit. Moreover, it corresponds with the control unit block after the computation of x and y coordinates of public and shared keys. It consists of 88 states. State 0 is an idle state. However, the details for other states are as follows. •

Affine to projective coordinates conversion: Affine to projective conversions is performed from state 1 to state 6. Each state requires one clock cycle. So a total of six clock cycles are needed to compute affine to projective conversions.

The simulation waveform over GF(2163) is shown in Fig. 3. It ensures that the proposed coprocessor architecture successfully generates the shared key value when the public and private/secret keys are input to the system. The generated shared key value could be used to perform key authentication or encryption and decryption between two wireless sensor nodes.

Our proposed coprocessor architecture over GF(2163) and GF(2233) is implemented in Verilog, using Vivado IDE (Integrated Design Environment) tool. The implementation results is performed for a 28 nm technology on Virtex-7 (xc7vx485tffg1157-1) FPGA. The input parameters have been selected from NIST standardized document [16]. Consequently, the results are provided after place-and-route in Table 2. The field length (m) is presented in column one. Columns two, three and four present the slices, LUTs and FFs respectively. The clock frequency is presented in column five. The total number of required clock cycles (CCs) and latency (in μs) figures are given in columns six and seven, respectively. Similarly, the clock cycles (CCs) and latency (in μs) values for shared key generation are given in columns eight and nine, respectively. Finally, the consumed power (in mW) is provided in the last column. The area and frequency values are obtained from the Vivado IDE tool. The clock cycles are calculated using Eqs. (1) and (2), the details are already described in Section 3.4. The latency values are calculated using Eq. (3). To obtain power values, we have used a Vivado Power Analysis tool [40]. (3)Latency(μs)=ClockCycles(CCs)Frequency(MHz)

Due to different field lengths (i.e., 163 and 233), the proposed architecture over GF(2163) utilizes 1351, 5403 and 1306 FPGA slices, LUTs and FFs that are comparatively 0.75 (ratio of 1351 over 1789), 0.75 (ratio of 5403 over 7156) and 0.70 (ratio of 1306 over 1864) times lower than the design implemented over GF(2233) field. The use of a coprocessor implementation style and a digit-serial finite field multiplier results in a maximum frequency of 250 and 235 MHz over GF(2163) and GF(2233), respectively. By employing different optimization techniques such as pipelining, parallelism and scheduling for PA and PD instructions of columns two and four of Table 1, the clock frequency of our architecture could be improved for high-speed cryptographic applications.

Despite the hardware resources and operational frequency, our design requires 10125 and 20250 cycles for one public and shared keys computation over GF(2163). Similarly, for public and shared key generations, the clock cycle cost of our architecture over GF(2233) is 18613 and 37226, respectively. With some area (hardware resources) overhead, the clock cycles could be improved by employing bit-parallel or digit-parallel finite field multipliers inside the ALU of our coprocessor architecture. The computational cost in terms of latency is 40.50 and 81.00 μs over GF(2163) for one public key and shared key generation, respectively. For similar operations, the latency values over GF(2233) is 79.20 and 158.40 μs. As expected, the computational cost (in terms of both CCs and latency) increases with the increase in the binary field length (i.e., from 163 to 233). The latency of the proposed design could be improved by (i) reducing the clock cycles and (ii) maximizing the clock frequency.

Utilization of a digit-serial multiplier with a smaller digit size of 24-bit results in lower power consumption of 0.91 and 1.37 mW over GF(2163) and GF(2233), respectively. The use of smaller digit length results in a lower computational power with clock cycles overhead [11,41]. The hardware resources and power consumption of our proposed design could be improved further by employing a bit-serial multiplication architecture as used in [21].

The circuit layout of our proposed coprocessor architecture over GF(2163) is shown in Fig. 4. It shows that the proposed coprocessor architecture is routable on our selected Virtex-7 (xc7vx485tffg1157-1) FPGA without the DRC (design rule check) and timing violations.

On Virtex-7 over GF(2233), the proposed architecture consumes 2.86 (ratio of 5120 with 1789) times lesser slices with respect to [11]. The reason is the use of a digit-serial multiplier (24-bits). On the other hand, a 32-bit digit size is used in a parallel way in [11]. Moreover, this comparison shows that the longer digits result in higher hardware resources. Additionally, the digit-parallel multiplication approach with a digit length of 32-bits results in lower clock cycles which ultimately improves the latency value in [11]. The use of 2-stage pipelining improves the clock frequency in [17].

As shown in Table 3, the architecture of [21] over GF(2163) on Virtex-7 utilizes lower FPGA LUTs and takes less time for computation with respect to the proposed design. The reason is the computation of only the PM operation of ECC while our design considers the ECDH protocol implementation for key authentication. As the objective of our work is to generate the shared key for wireless sensor nodes and RFID applications, the proposed architecture can operate up to a maximum of 250 MHz while the architecture of [21] can operate on 909 MHz frequency as the intent is to optimize only the PM operation.

Apart from the hardware resources and timing results, the power consumption of [21] is 0.73 mW for one PM execution. In our work, a 0.91 mW is consumed for one shared key generation using ECDH protocol. Furthermore, our design utilizes Montgomery PM algorithm for the implementation of the ECDH protocol of ECC as it is inherently secure against timing and power analysis attacks. On the other hand, the Lopez Dahab PM algorithm is used in [21]. In Lopez Dahab PM algorithm, swapping between the PA and PD computations is needed whenever the inspected value of the key-bit becomes 1. The need for swapping requires additional clock cycles which shows that the architecture of [21] is not secure against the timing and power analysis attacks. To summarize, our architecture is protected against timing and power analysis attacks and consumes a comparable power than the power consumption of [21].

The Stratix-II design of [32] achieves an operational frequency of 187 MHz that is comparatively 1.33 (ratio of 250 with 187) times lower than our Virtex-7 implementation over GF(2163). In other words, our work is 1.33 times faster in terms of frequency. However, our architecture requires more computational time as we have described a flexible design while a dedicated architecture of PM is discussed in [32]. The comparison to area and power values are not possible to provide as the relevant information is not presented in the reference design. On Virtex-7 over GF(2163), our architecture utilizes 2.70 (ratio of 3657 with 1351) times lower FPGA slices than [39]. The reason is the use of a digit-serial multiplier with a digit size of 24-bits in our work while a bit-parallel Karatsuba multiplier is considered for implementation in [39]. The use of bit-parallel multiplier results in lower clock cycles which eventually improves the latency value in [39]. Moreover, our design is 1.85 (ratio of 250 with 135) times faster in terms of operational frequency. Similar to [32], the power comparison is not possible because the corresponding information is not described in the reference design.

The most recent design of [14] for key-authentication using ECDH protocol over GF(2233) on Virtex-7 FPGA results in 2.85 (ratio of 5102 with 1789) times higher slices as compared to our work. On the other hand, the design of [14] is 5.09 (ratio of 158.40 with 31.08) times faster in terms of computational time as compared to our architecture. The reason is the use of bit-parallel Karatsuba multiplier in the datapath of [14] while in our design, we employed a digit-serial multiplication approach. Another reason is the use of 2-stage pipelining to shorten the critical path which eventually increases the clock frequency with an area overhead. Power comparison is not possible as the corresponding information is not given in [14].

The efficient implementation of [17] for key authentication using ECDH protocol over GF(2163) on Artix-7 results in 603 slices that is comparatively lower than our work (1389). On the other hand, the architecture of [17] uses 2 and 21 sizes of 36 and 18 kb BRAMs. In addition, it utilizes 38 DSP48A1 FPGA slices. In our design, we are not using the BRAMs as we implemented a RegFile as an array of registers to accommodate the initial, intermediate and final results. Therefore, a fair comparison to area is challenging. Despite the hardware resources, our architecture is 24 (ratio of 247 with 10) times faster in terms of clock frequency. Moreover, our architecture requires 2.40 (ratio of 167.70 with 81.98) times lower computational time (latency). Whenever, the power consumption of [17] is concerned for comparison, our architecture is 29.62 (ratio of 40 mW with 1.35 mW times efficient. The potential reason for higher power consumption and computational time in [17] is the support for various cryptographic algorithms such as SHA (Secure Hash Algorithm) for secure hashing while our design is specific to the ECDH protocol.

On similar Spartan-6 device, the design of [24] over GF(2163) for ECDH implementation is 2.41 (ratio of 13663 with 5652) times less area efficient as compared to our work. It is due to the employment of several finite field multipliers in their architecture. O the other hand, we have utilized a single serial multiplier. Moreover, the proposed design provides a speedup of 7 (ratio of 231 with 33), as far as the operational frequency is concerned. In terms of latency, the proposed design requires 2.60 (ratio of 87.66 with 33.60) times the higher computational cost. The cause is the parallelism using multiple finite field multipliers in [24]. The dynamic power in [24] at 33 MHz is 571 mW which is comparatively 435.8 (ratio of 571 mW with 1.31 mW) times higher than this work. The Artix-7 design of [27] over GF(2163) results in higher slices (i.e., 8847) as compared to our design whereas we have used only 1389. The reason is the additional encryption and decryption operations along with the ECDH protocol implementation while we have considered only the ECDH protocol for shared key computation. Due to the simpler datapath in our design, the operational frequency is 1.07 (ratio of 247 with 229) times higher. The comparison to latency is not possible as their architecture results in encryption and decryption time while we have computed a shared key generation without the encryption and decryption operations.