[otbn,rtl] Shuffle order of multiplications for vectorized SIMD multiplications

[etterli]

This implements a shuffling mechanism which randomizes the order in which the vector elements are processed during a SIMD multiplication instruction.

Previously a multiplication processed a vector in a fixed order, from the least significant words to the highest words. Now we randomize this order by sampling a start index. The elements are still processed in a raising order but the random start index makes it harder for SCA to align computations.

This shuffling can be disabled for SCA analysis with the SecFixMacOpSeq parameter.

See also #30940 to understand where which randomness is used from URND.

[vogelpi]

Thanks @etterli , the RTL looks great! But I would prefer if the elem_idx signal was defined outside of the loop (see my comment for details).

[vogelpi]

I would rephrase this to something like:
"We don't actually recompute the shuffling index and instead just use the value from the predecoder. This means we will never detect a mismatch for this signal. But that is acceptable as the shuffling is SCA countermeasure on top of the masking expected to be implemented in software."

Because this talks a bit less about attacks but makes it clear to DV folks that there will be a coverage gap here.

[etterli]

Hm I see your point. But a different shuffle offset here leads to different 64-bit word selections. This would still be detected. The problem is that we do not have the URND bits from the last cycle available. So we just use the predecoded value again. The only attack point is now making the URND bits used by the predecoder static/deterministic. Then no mismatch can be detected. To fix this we would have to register the two URND bits and recompute the offset here. But I don't think this is needed. It would only benefit if a SCA and FI attack would be combined.

I tried to improve the comment.

             Predecoder              |       BN MAC

+------+       +-------------+   +------+
| URND |--o--> | Offset comp |-->| Flop |--------------------o-> To FSM
+------+  |    +-------------+   +------+                    |
          |                                                  v          
          |                                              Comparison
          |      This extra path would be required           ^
          |                      +------+   +-------------+  |
          +--------------------->| Flop |-->| Offset comp |--+
                                 +------+   +--------------

[vogelpi]

Yes, this is also my understanding and I think this is fine. Thanks @etterli !

[vogelpi]

Thanks for adding the drawing. IIUC, this means we'll use two bits of the current URND output to shuffle the order for the next vectorized multiplication. I think this is fine because:

• There is a permutation (netlist secret) which obfuscates which two bits are used.
• If it turned out to be a problem, software could add a NOP before the vectorized multiplication to ensure the same bits are not used for something else.

[etterli]

For completeness, SW can also make sure no MAI operation is ongoing. See also #30940 where and how URND is used.

[etterli]

Thanks @vogelpi for the review.

[etterli]

Hm I see your point. But a different shuffle offset here leads to different 64-bit word selections. This would still be detected. The problem is that we do not have the URND bits from the last cycle available. So we just use the predecoded value again. The only attack point is now making the URND bits used by the predecoder static/deterministic. Then no mismatch can be detected. To fix this we would have to register the two URND bits and recompute the offset here. But I don't think this is needed. It would only benefit if a SCA and FI attack would be combined.

I tried to improve the comment.

             Predecoder              |       BN MAC

+------+       +-------------+   +------+
| URND |--o--> | Offset comp |-->| Flop |--------------------o-> To FSM
+------+  |    +-------------+   +------+                    |
          |                                                  v          
          |                                              Comparison
          |      This extra path would be required           ^
          |                      +------+   +-------------+  |
          +--------------------->| Flop |-->| Offset comp |--+
                                 +------+   +--------------

[vogelpi]

CHANGE AUTHORIZED: hw/ip/otbn/data/otbn.hjson
CHANGE AUTHORIZED: hw/ip/otbn/rtl/otbn.sv
CHANGE AUTHORIZED: hw/ip/otbn/rtl/otbn_core.sv
CHANGE AUTHORIZED: hw/ip/otbn/rtl/otbn_instruction_fetch.sv
CHANGE AUTHORIZED: hw/ip/otbn/rtl/otbn_mac_bignum.sv
CHANGE AUTHORIZED: hw/ip/otbn/rtl/otbn_mac_bignum_fsm.sv
CHANGE AUTHORIZED: hw/ip/otbn/rtl/otbn_pkg.sv
CHANGE AUTHORIZED: hw/ip/otbn/rtl/otbn_predecode.sv
CHANGE AUTHORIZED: hw/top_earlgrey/rtl/autogen/earlgrey_pd_main.sv
CHANGE AUTHORIZED: hw/top_earlgrey/rtl/autogen/top_earlgrey.sv

This PR implements an approved feature.

[vogelpi]

@nasahlpa , would you mind authorizing this PR too please?

[nasahlpa]

CHANGE AUTHORIZED: hw/ip/otbn/data/otbn.hjson
CHANGE AUTHORIZED: hw/ip/otbn/rtl/otbn.sv
CHANGE AUTHORIZED: hw/ip/otbn/rtl/otbn_core.sv
CHANGE AUTHORIZED: hw/ip/otbn/rtl/otbn_instruction_fetch.sv
CHANGE AUTHORIZED: hw/ip/otbn/rtl/otbn_mac_bignum.sv
CHANGE AUTHORIZED: hw/ip/otbn/rtl/otbn_mac_bignum_fsm.sv
CHANGE AUTHORIZED: hw/ip/otbn/rtl/otbn_pkg.sv
CHANGE AUTHORIZED: hw/ip/otbn/rtl/otbn_predecode.sv
CHANGE AUTHORIZED: hw/top_earlgrey/rtl/autogen/earlgrey_pd_main.sv
CHANGE AUTHORIZED: hw/top_earlgrey/rtl/autogen/top_earlgrey.sv

This PR implements an approved feature.