Adding ECDH feature to ECC engine (#577)

* Merge pull request #426 from chipsalliance/user/dev/kupadhyayula/ECDH

ECDH rtl, tb, uvm updates

* Update signal names in cov_if

* resolved conflict

* fixed DH cmd

* ECDH smoketests

* fixed sha512 masked tb

* updated ecc rdl

* updated reg docs

* fixed lint issue

* MICROSOFT AUTOMATED PIPELINE: Stamp 'mojtabab-msft-ecdh' with updated timestamp and hash after successful run

* renamed ecdsa to ecc

* removed commented-out codes

* MICROSOFT AUTOMATED PIPELINE: Stamp 'mojtabab-msft-ecdh' with updated timestamp and hash after successful run

* removed nonce from ECDH and documented ECDH into spec

* MICROSOFT AUTOMATED PIPELINE: Stamp 'mojtabab-msft-ecdh' with updated timestamp and hash after successful run

* MICROSOFT AUTOMATED PIPELINE: Stamp 'mojtabab-msft-ecdh' with updated timestamp and hash after successful run

---------

Co-authored-by: upadhyayulakiran <[email protected]>
Co-authored-by: Kiran Upadhyayula <[email protected]>
Co-authored-by: Mojtaba Bisheh Niasar <[email protected]>

.github/workflow_metadata/pr_hash

@@ -1 +1 @@
-87d12e3f1a9f2c2fca2dc4b1da0c727bed238bfaf9919890da2d84936cb226568e05b7a33ff6f6a4ce2e88fd9da0ea00
+e0a04a4e5783f4d92cda3bf8038ad5867d6ee7edb5bb8018db6c11b9171ad45284eeb77d114732c920fd48d834139395

.github/workflow_metadata/pr_timestamp

@@ -1 +1 @@
-1724699665
+1724776472

README.md

@@ -201,7 +201,7 @@ Verilog file lists are generated via VCS and included in the config directory fo
       - CALIPTRA_INTERNAL_I3C
       - CALIPTRA_INTERNAL_TRNG
 1. Copy the test generator scripts to the run output directory:
-    - [src/ecc/tb/ecdsa_secp384r1.exe](src/ecc/tb/ecdsa_secp384r1.exe)
+    - [src/ecc/tb/ecc_secp384r1.exe](src/ecc/tb/ecc_secp384r1.exe)
         * Necessary for [randomized_pcr_signing](src/integration/test_suites/randomized_pcr_signing)
         * OPTIONAL otherwise
     - [src/doe/tb/doe_test_gen.py](src/doe/tb/doe_test_gen.py)
@@ -304,7 +304,7 @@ The UVM Framework generation tool was used to create the baseline UVM testbench
 1. ALL compilation steps may be completed by using the file-list found at `src/<block>/uvmf_<name>/config/<name>.vf`
 1. NOTE: `Caliptra/src/<block>/uvmf_<name>/uvmf_template_output/project_benches/<block>/tb/testbench/hdl_top.sv` is the top-level TB wrapper for the system
 1. Copy the test generator scripts to the run output directory:
-    - [src/ecc/tb/ecdsa_secp384r1.exe](src/ecc/tb/ecdsa_secp384r1.exe)
+    - [src/ecc/tb/ecc_secp384r1.exe](src/ecc/tb/ecc_secp384r1.exe)
         * Necessary for ECC unittest
     - [src/hmac/tb/test_gen.py](src/hmac/tb/test_gen.py)
         * Required for uvmf_hmac unittest

docs/CaliptraHardwareSpecification.md

@@ -1107,10 +1107,12 @@ For information, see SCA countermeasure in the [HMAC384](#hmac384) section.
 
 ## ECC
 
-The ECC unit includes the ECDSA (Elliptic Curve Digital Signature Algorithm) engine, offering a variant of the cryptographically secure Digital Signature Algorithm (DSA), which uses elliptic curve (ECC). A digital signature is an authentication method in which a public key pair and a digital certificate are used as a signature to verify the identity of a recipient or sender of information.
+The ECC unit includes the ECDSA (Elliptic Curve Digital Signature Algorithm) engine and the ECDH (Elliptic Curve Diffie-Hellman Key-Exchange) engine, offering a variant of the cryptographically secure Digital Signature Algorithm (DSA) and Diffie-Hellman Key-Exchange (DH), which uses elliptic curve (ECC). A digital signature is an authentication method in which a public key pair and a digital certificate are used as a signature to verify the identity of a recipient or sender of information.
 
 The hardware implementation supports deterministic ECDSA, 384 Bits (Prime Field), also known as NIST-Secp384r1, described in RFC6979.
 
+The hardware implementation also supports ECDH, 384 Bits (Prime Field), also known as NIST-Secp384r1, described in SP800-56A.
+
 Secp384r1 parameters are shown in the following figure.
 
 *Figure 31: Secp384r1 parameters*
@@ -1125,6 +1127,8 @@ The ECDSA consists of three operations, shown in the following figure.
 
 ![](./images/ECDSA_ops.png)
 
+The ECDH also consists of the sharedkey generation.
+
 #### KeyGen
 
 In the deterministic key generation, the paired key of (privKey, pubKey) is generated by KeyGen(seed, nonce), taking a deterministic seed and nonce. The KeyGen algorithm is as follows:
@@ -1152,17 +1156,25 @@ The signature (r, s) can be verified by Verify(pubKey ,h ,r, s) considering the
 * Take r’ = R'x mod n, while R'x is x coordinate of R’=(R'x, R'y)
 * Verify the signature by comparing whether r' == r
 
+#### ECDH sharedkey
+
+In ECDH sharedkey generation, the shared key is generated by ECDH_sharedkey(privKey_A, pubKey_B), taking an own prikey and other party pubkey. The ECDH sharedkey algorithm is as follows:
+
+* Compute P = sharedkey(privkey_A, pubkey_b) where P(x,y) is a point on ECC.
+* Output sharedkey = Px, where Px is x coordinate of P.
+
+
 ### Architecture
 
 The ECC top-level architecture is shown in the following figure.
 
-*Figure 33: ECDSA architecture*
+*Figure 33: ECC architecture*
 
-![](./images/ECDSA_arch.png)
+![](./images/ECC_arch.png)
 
 ### Signal descriptions
 
-The ECDSA architecture inputs and outputs are described in the following table.
+The ECC architecture inputs and outputs are described in the following table.
 
 
 | Name                       | Input or output | Description  |
@@ -1182,15 +1194,16 @@ The ECDSA architecture inputs and outputs are described in the following table.
 | r\[383:0\]                 | output          | The signature value of the given priveKey/message.                                                                         |
 | s\[383:0\]                 | output          | The signature value of the given priveKey/message.                                                                         |
 | r’\[383:0\]                | Output          | The signature verification result.                                                                                         |
+| DH_sharedkey\[383:0\]      | output          | The generated shared key in the ECDH sharedkey operation.                                                                         |
 | valid                      | output          | When HIGH, the signal indicates the result is ready.                                                                       |
 
 ### Address map
 
-The ECDSA address map is shown here: [ecc\_reg — clp Reference (chipsalliance.github.io)](https://chipsalliance.github.io/caliptra-rtl/main/internal-regs/?p=clp.ecc_reg).
+The ECC address map is shown here: [ecc\_reg — clp Reference (chipsalliance.github.io)](https://chipsalliance.github.io/caliptra-rtl/main/internal-regs/?p=clp.ecc_reg).
 
 ### Pseudocode
 
-The following pseudocode blocks demonstrate example implementations for KeyGen, Signing, and Verifying.
+The following pseudocode blocks demonstrate example implementations for KeyGen, Signing, Verifying, and ECDH sharedkey.
 
 #### KeyGen
 
@@ -1210,9 +1223,15 @@ The following pseudocode blocks demonstrate example implementations for KeyGen,
 
 ![](./images/verify_pseudo.png)
 
+#### ECDH sharedkey
+
+*Figure 37: ECDH sharedkey pseudocode*
+
+![](./images/sharedkey_pseudo.png)
+
 ### SCA countermeasure
 
-The described ECDSA has three main routines: KeyGen, Signing, and Verifying. Since the Verifying routine requires operation with public values rather than a secret value, our side-channel analysis does not cover this routine. Our evaluation covers the KeyGen and Signing routines where the secret values are processed. 
+The described ECC has four main routines: KeyGen, Signing, Verifying, and ECDH sharedkey. Since the Verifying routine requires operation with public values rather than a secret value, our side-channel analysis does not cover this routine. Our evaluation covers the KeyGen, Signing, and ECDH sharedkey routines where the secret values are processed. 
 
 KeyGen consists of HMAC DRBG and scalar multiplication, while Signing first requires a message hashing and then follows the same operations as KeyGen (HMAC DRBG and scalar multiplication). The last step of Signing is generating “S” as the proof of signature. Since HMAC DRBG and hash operations are evaluated separately in our document, this evaluation covers scalar multiplication and modular arithmetic operations. 
 
@@ -1224,7 +1243,7 @@ Implementation of complete unified addition formula for the scalar multiplicatio
 
 To protect the architecture against horizontal power/electromagnetic (EM) and differential power analysis (DPA) attacks, several countermeasures are embedded in the design [9]. Since these countermeasures require random inputs, HMAC-DRBG is fed by IV to generate these random values.
 
-Since HMAC-DRBG generates random value in a deterministic way, firmware MUST feed different IV to ECC engine for EACH keygen and signing operation. 
+Since HMAC-DRBG generates random value in a deterministic way, firmware MUST feed different IV to ECC engine for EACH keygen, signing, and ECDH sharedkey operation. 
 
 #### Base point randomization
 
@@ -1272,7 +1291,7 @@ The state machine of HMAC\_DRBG utilization is shown in the following figure, in
 2. KEYGEN PRIVKEY: Running HMAC\_DRBG with seed and nonce to generate the privkey in KEYGEN operation.
 3. SIGNING NONCE: Running HMAC\_DRBG based on RFC6979 in SIGNING operation with privkey and hashed\_msg.
 
-*Figure 37: HMAC\_DRBG utilization*
+*Figure 38: HMAC\_DRBG utilization*
 
 ![](./images/HMAC_DRBG_util.png)
 
@@ -1288,7 +1307,7 @@ In SCA random generator state:
 
 The data flow of the HMAC\_DRBG operation in keygen operation mode is shown in the following figure.
 
-*Figure 38: HMAC\_DRBG data flow*
+*Figure 39: HMAC\_DRBG data flow*
 
 ![](./images/HMAC_DRBG_data.png)
 
@@ -1298,7 +1317,7 @@ Test vector leakage assessment (TVLA) provides a robust test using a 𝑡-test.
 
 In practice, observing a t-value greater than a specific threshold (mainly 4.5) indicates the presence of leakage. However, in ECC, due to its latency, around 5 million samples are required to be captured. This latency leads to many false positives and the TVLA threshold can be considered a higher value than 4.5. Based on the following figure from “Side-Channel Analysis and Countermeasure Design for Implementation of Curve448 on Cortex-M4” by Bisheh-Niasar et. al., the threshold can be considered equal to 7 in our case.
 
-*Figure 39: TVLA threshold as a function of the number of samples per trace*
+*Figure 40: TVLA threshold as a function of the number of samples per trace*
 
 ![](./images/TVLA_threshold.png)
 
@@ -1308,21 +1327,21 @@ In practice, observing a t-value greater than a specific threshold (mainly 4.5)
 The TVLA results for performing seed/nonce-dependent leakage detection using 200,000 traces is shown in the following figure. Based on this figure, there is no leakage in ECC keygen by changing the seed/nonce after 200,000 operations.
 
 
-*Figure 40: seed/nonce-dependent leakage detection using TVLA for ECC keygen after 200,000 traces*
+*Figure 41: seed/nonce-dependent leakage detection using TVLA for ECC keygen after 200,000 traces*
 
 ![](./images/tvla_keygen.png)
 
 ##### Signing TVLA
 
 The TVLA results for performing privkey-dependent leakage detection using 20,000 traces is shown in the following figure. Based on this figure, there is no leakage in ECC signing by changing the privkey after 20,000 operations.
 
-*Figure 41: privkey-dependent leakage detection using TVLA for ECC signing after 20,000 traces*
+*Figure 42: privkey-dependent leakage detection using TVLA for ECC signing after 20,000 traces*
 
 ![](./images/TVLA_privekey.png)
 
 The TVLA results for performing message-dependent leakage detection using 64,000 traces is shown in the following figure. Based on this figure, there is no leakage in ECC signing by changing the message after 64,000 operations.
 
-*Figure 42: Message-dependent leakage detection using TVLA for ECC signing after 64,000 traces*
+*Figure 43: Message-dependent leakage detection using TVLA for ECC signing after 64,000 traces*
 
 ![](./images/TVLA_msg_dependent.png)
 
@@ -1361,13 +1380,13 @@ LMS cryptography is a type of hash-based digital signature scheme that was stand
 
 Caliptra supports only LMS verification using a software/hardware co-design approach. Hence, the LMS accelerator reuses the SHA256 engine to speedup the Winternitz chain by removing software-hardware interface overhead. The LMS-OTS verification algorithm is shown in follwoing figure:
 
-*Figure 43: LMS-OTS Verification algorithm*
+*Figure 44: LMS-OTS Verification algorithm*
 
 ![](./images/LMS_verifying_alg.png)
 
 The high-level architecture of LMS is shown in the following figure.
 
-*Figure 44: LMS high-level architecture*
+*Figure 45: LMS high-level architecture*
 
 ![](./images/LMS_high_level.png)
 
@@ -1391,7 +1410,7 @@ LMS parameters are shown in the following table:
 
 The Winternitz hash chain can be accelerated in hardware to enhance the performance of the design. For that, a configurable architecture is proposed that can reuse SHA256 engine. The LMS accelerator architecture is shown in the following figure, while H is SHA256 engine.
 
-*Figure 45: Winternitz chain architecture*
+*Figure 46: Winternitz chain architecture*
 
 ![](./images/LMS_wntz_arch.png)
 
@@ -1609,6 +1628,7 @@ The following terminology is used in this document.
 | DRBG         | Deterministic Random Bit Generator             |
 | DWORD        | 32-bit (4-byte) data element                   |
 | ECDSA        | Elliptic Curve Digital Signature Algorithm     |
+| ECDH         | Elliptic Curve Deffie-Hellman Key Exchange     |
 | FMC          | FW First Mutable Code                          |
 | FSM          | Finite State Machine                           |
 | GPU          | Graphics Processing Unit                       |
@@ -1662,5 +1682,6 @@ The following terminology is used in this document.
 13. CHIPS Alliance, “RISC-V VeeR EL2 Programmer’s Reference Manual” \[Online\] Available at https://github.com/chipsalliance/Cores-VeeR-EL2/blob/main/docs/RISC-V_VeeR_EL2_PRM.pdf. 
 14. “The RISC-V Instruction Set Manual, Volume I: User-Level ISA, Document Version 20191213”, Editors Andrew Waterman and Krste Asanovi ́c, RISC-V Foundation, December 2019. Available at https://riscv.org/technical/specifications/. 
 15. “The RISC-V Instruction Set Manual, Volume II: Privileged Architecture, Document Version 20211203”, Editors Andrew Waterman, Krste Asanovi ́c, and John Hauser, RISC-V International, December 2021. Available at https://riscv.org/technical/specifications/. 
+16. NIST SP 800-56A, Rev 3: "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography", 2018, |
 
 <sup>[1]</sup> _Caliptra.**  **Spanish for “root cap” and describes the deepest part of the root_

src/ecc/coverage/ecc_top_cov_if.sv

@@ -77,8 +77,8 @@ interface ecc_top_cov_if
     assign ecc_cmd = ecc_top.ecc_dsa_ctrl_i.cmd_reg;
     assign pcr_sign_mode = ecc_top.ecc_dsa_ctrl_i.pcr_sign_mode;
     assign zeroize = ecc_top.ecc_dsa_ctrl_i.zeroize_reg;
-    assign ready = ecc_top.ecc_dsa_ctrl_i.dsa_ready_reg;
-    assign valid = ecc_top.ecc_dsa_ctrl_i.dsa_valid_reg;
+    assign ready = ecc_top.ecc_dsa_ctrl_i.ecc_ready_reg;
+    assign valid = ecc_top.ecc_dsa_ctrl_i.ecc_valid_reg;
 
     always_ff @(posedge clk) begin
         if (!reset_n) begin

src/ecc/rtl/ecc_arith_unit.sv

@@ -45,7 +45,7 @@ module ecc_arith_unit
     input wire           zeroize,
 
     // DATA PORT
-    input  wire [2 : 0]                     ecc_cmd_i,
+    input  wire [3 : 0]                     ecc_cmd_i,
     input  wire                             sca_en_i,
     input  wire [ADDR_WIDTH-1 : 0]          addr_i,
     input  wire                             wr_op_sel_i,