Hi,
I am trying to finalize the scan exclusion list for Caliptra SS as per the integration spec requirements, but the requirements are a bit vague (ex: exclude all registers driven by cipher keys in otp_ctrl_part_pkg without mentioning the name of the parameter) so I am worried about accurately capturing the requirements and missing something critical to ensure Caliptra SS remains secure. I am hoping we could use this ticket to review the scan exclusion list and get to an approved list. There is a task to improve this part of the Caliptra SS documentation in the future (#730), so maybe this approved list can then be used as baseline for that as well.
Current scan exclusions:
Caliptra:
caliptra_ss_top/caliptra_top_dut/cptra_scan_mode_Latched_d_reg
caliptra_ss_top/caliptra_top_dut/cptra_scan_mode_Latched_f_reg
caliptra_ss_top/caliptra_top_dut/soc_ifc_top1/i_soc_ifc_reg/*obf_key*
caliptra_ss_top/caliptra_top_dut/*cptra_csr_hmac_key_reg*
Caliptra SS:
caliptra_ss_top/u_otp_ctrl/gen_partitions*1*/gen_buffered/u_part_buf/*u_otp_ctrl_ecc_reg*
caliptra_ss_top/u_otp_ctrl/gen_partitions*2*/gen_buffered/u_part_buf/*u_otp_ctrl_ecc_reg*
caliptra_ss_top/u_otp_ctrl/gen_partitions*3*/gen_buffered/u_part_buf/*u_otp_ctrl_ecc_reg*
caliptra_ss_top/u_otp_ctrl/gen_partitions*4*/gen_buffered/u_part_buf/*u_otp_ctrl_ecc_reg*
caliptra_ss_top/u_otp_ctrl/gen_partitions*5*/gen_buffered/u_part_buf/*u_otp_ctrl_ecc_reg*
- Note: looking at the partitions there is a buffered SECRET_LC_TRANSITION_PARTITION at index 7. Is it safe to ignore that one? The spec mentions that LC Token is safe to ignore, but that is "token" while index 7 is "transition" and has "secret" in the name.
The other three requirements in the spec are for drivers + loads of "otp_broadcast_o", loads only of "PRESENT cipher keys", and the raw unlock token. The broadcast/cipher keys have rather large fanouts so I want to confirm the specifics before I exclude more than is really needed and lose out on scan coverage.
Tracing "otp_broadcast_o" there are 100s of pins:
caliptra_ss_top/u_otp_ctrl/otp_broadcast_o_valid_3_
caliptra_ss_top/u_otp_ctrl/otp_broadcast_o_valid_2_
caliptra_ss_top/u_otp_ctrl/otp_broadcast_o_valid_1_
caliptra_ss_top/u_otp_ctrl/otp_broadcast_o_valid_0_
caliptra_ss_top/u_otp_ctrl/otp_broadcast_o_secret_prod_partition_3_data_secret_prod_partition_3_digest_63_
caliptra_ss_top/u_otp_ctrl/otp_broadcast_o_secret_prod_partition_3_data_secret_prod_partition_3_digest_62_
caliptra_ss_top/u_otp_ctrl/otp_broadcast_o_secret_prod_partition_3_data_secret_prod_partition_3_digest_61_
caliptra_ss_top/u_otp_ctrl/otp_broadcast_o_secret_prod_partition_3_data_secret_prod_partition_3_digest_60_
... (and so on)
Searching for otp_bradcast_o*reg* there are also quite a few:
caliptra_ss_top/u_otp_ctrl/MBF_otp_broadcast_o_reg_secret_manuf_partition_data_cptra_core_uds_seed_107___otp_broadcast_o_reg_secret_manuf_partition_data_cptra_core_uds_seed_106___otp_broadcast_o_reg_secret_manuf_partition_data_cptra_core_uds_seed_105___otp_broadcast_o_reg_secret_manuf_partition_data_cptra_core_uds_seed_104___otp_broadcast_o_reg_secret_manuf_partition_data_cptra_core_uds_seed_103___otp_broadcast_o_reg_secret_manuf_partition_data_cptra_core_uds_seed_102___otp_broadcast_o_reg_secret_manuf_partition_data_cptra_core_uds_seed_101___otp_broadcast_o_reg_secret_manuf_partition_data_cptra_core_uds_seed_100_
caliptra_ss_top/u_otp_ctrl/MBF_otp_broadcast_o_reg_secret_prod_partition_2_data_cptra_core_field_entropy_2_19___otp_broadcast_o_reg_secret_prod_partition_2_data_cptra_core_field_entropy_2_18___otp_broadcast_o_reg_secret_prod_partition_2_data_cptra_core_field_entropy_2_17___otp_broadcast_o_reg_secret_prod_partition_2_data_cptra_core_field_entropy_2_16___otp_broadcast_o_reg_secret_prod_partition_2_data_cptra_core_field_entropy_2_15___otp_broadcast_o_reg_secret_prod_partition_2_data_cptra_core_field_entropy_2_14___otp_broadcast_o_reg_secret_prod_partition_2_data_cptra_core_field_entropy_2_13___otp_broadcast_o_reg_secret_prod_partition_2_data_cptra_core_field_entropy_2_12_
... (and so on)
So would caliptra_ss_top/u_otp_ctrl/*otp_broadcast_o*reg* be the correct exclusion regex here?
As for the cipher keys it does not mention which exact parameter in otp_ctrl_part_pkg.sv it is. I assume it is referring to "RndCnstKey" (SEC_CM: SECRET.MEM.SCRAMBLE)?
The signal driven by this constant is "caliptra_ss_top/u_otp_ctrl/u_otp_ctrl_scrmbl/rnd_cnst_key_anchor" before it goes into various combo logic and a large fanout. Tracing a few paths I ended up with something like:
caliptra_ss_top/u_otp_ctrl/u_otp_ctrl_scrmbl/MBF_key_state_q_reg_79___key_state_q_reg_78___key_state_q_reg_77___key_state_q_reg_76___key_state_q_reg_75___key_state_q_reg_74___key_state_q_reg_73___key_state_q_reg_72_
For this I could use a regex such as: caliptra_ss_top/u_otp_ctrl/u_otp_ctrl_scrmbl/*key_state*reg*
Is this the correct regex to use? Are there any others?
Finally the raw unlock token: Here the integration spec mentions to exclude "caliptra_ss_top/u_lc_ctrl/u_lc_ctrl_fsm/hashed_token_mux*" and "caliptra_ss_top/u_lc_ctrl/lc_ctrl_fsm/hashed_tokens*", but neither of these are scannable flops. In fact the spec itself mentions " it is stored in the plaintext in gates". Since these are gates, how is scan (or scan exclusions) supposed to work? For now we are not adding any exclusion for these two, as there are no flops involved in the signals mentioned above. Our logic outside that is driving this input to Caliptra does not involve any flops either (its a constant).
Also: There is a set of digest registers for secret partitions, but there are no instructions for excluding them. I was wondering if maybe they would be good to exclude as well:
caliptra_ss_top/u_otp_ctrl/u_reg_core/u_secret_lc_transition_partition_digest_*
caliptra_ss_top/u_otp_ctrl/u_reg_core/u_secret_manuf_partition_digest_*
caliptra_ss_top/u_otp_ctrl/u_reg_core/u_secret_prod_partition_*_digest_*
Please let me know if you have any questions or need me to trace other paths for these signals. I want to make sure I get these scan exclusions right.
Best Regards,
Nicolas
Hi,
I am trying to finalize the scan exclusion list for Caliptra SS as per the integration spec requirements, but the requirements are a bit vague (ex: exclude all registers driven by cipher keys in otp_ctrl_part_pkg without mentioning the name of the parameter) so I am worried about accurately capturing the requirements and missing something critical to ensure Caliptra SS remains secure. I am hoping we could use this ticket to review the scan exclusion list and get to an approved list. There is a task to improve this part of the Caliptra SS documentation in the future (#730), so maybe this approved list can then be used as baseline for that as well.
Current scan exclusions:
Caliptra:
caliptra_ss_top/caliptra_top_dut/cptra_scan_mode_Latched_d_reg
caliptra_ss_top/caliptra_top_dut/cptra_scan_mode_Latched_f_reg
caliptra_ss_top/caliptra_top_dut/soc_ifc_top1/i_soc_ifc_reg/*obf_key*
caliptra_ss_top/caliptra_top_dut/*cptra_csr_hmac_key_reg*
Caliptra SS:
caliptra_ss_top/u_otp_ctrl/gen_partitions*1*/gen_buffered/u_part_buf/*u_otp_ctrl_ecc_reg*
caliptra_ss_top/u_otp_ctrl/gen_partitions*2*/gen_buffered/u_part_buf/*u_otp_ctrl_ecc_reg*
caliptra_ss_top/u_otp_ctrl/gen_partitions*3*/gen_buffered/u_part_buf/*u_otp_ctrl_ecc_reg*
caliptra_ss_top/u_otp_ctrl/gen_partitions*4*/gen_buffered/u_part_buf/*u_otp_ctrl_ecc_reg*
caliptra_ss_top/u_otp_ctrl/gen_partitions*5*/gen_buffered/u_part_buf/*u_otp_ctrl_ecc_reg*
The other three requirements in the spec are for drivers + loads of "otp_broadcast_o", loads only of "PRESENT cipher keys", and the raw unlock token. The broadcast/cipher keys have rather large fanouts so I want to confirm the specifics before I exclude more than is really needed and lose out on scan coverage.
Tracing "otp_broadcast_o" there are 100s of pins:
caliptra_ss_top/u_otp_ctrl/otp_broadcast_o_valid_3_
caliptra_ss_top/u_otp_ctrl/otp_broadcast_o_valid_2_
caliptra_ss_top/u_otp_ctrl/otp_broadcast_o_valid_1_
caliptra_ss_top/u_otp_ctrl/otp_broadcast_o_valid_0_
caliptra_ss_top/u_otp_ctrl/otp_broadcast_o_secret_prod_partition_3_data_secret_prod_partition_3_digest_63_
caliptra_ss_top/u_otp_ctrl/otp_broadcast_o_secret_prod_partition_3_data_secret_prod_partition_3_digest_62_
caliptra_ss_top/u_otp_ctrl/otp_broadcast_o_secret_prod_partition_3_data_secret_prod_partition_3_digest_61_
caliptra_ss_top/u_otp_ctrl/otp_broadcast_o_secret_prod_partition_3_data_secret_prod_partition_3_digest_60_
... (and so on)
Searching for otp_bradcast_o*reg* there are also quite a few:
caliptra_ss_top/u_otp_ctrl/MBF_otp_broadcast_o_reg_secret_manuf_partition_data_cptra_core_uds_seed_107___otp_broadcast_o_reg_secret_manuf_partition_data_cptra_core_uds_seed_106___otp_broadcast_o_reg_secret_manuf_partition_data_cptra_core_uds_seed_105___otp_broadcast_o_reg_secret_manuf_partition_data_cptra_core_uds_seed_104___otp_broadcast_o_reg_secret_manuf_partition_data_cptra_core_uds_seed_103___otp_broadcast_o_reg_secret_manuf_partition_data_cptra_core_uds_seed_102___otp_broadcast_o_reg_secret_manuf_partition_data_cptra_core_uds_seed_101___otp_broadcast_o_reg_secret_manuf_partition_data_cptra_core_uds_seed_100_
caliptra_ss_top/u_otp_ctrl/MBF_otp_broadcast_o_reg_secret_prod_partition_2_data_cptra_core_field_entropy_2_19___otp_broadcast_o_reg_secret_prod_partition_2_data_cptra_core_field_entropy_2_18___otp_broadcast_o_reg_secret_prod_partition_2_data_cptra_core_field_entropy_2_17___otp_broadcast_o_reg_secret_prod_partition_2_data_cptra_core_field_entropy_2_16___otp_broadcast_o_reg_secret_prod_partition_2_data_cptra_core_field_entropy_2_15___otp_broadcast_o_reg_secret_prod_partition_2_data_cptra_core_field_entropy_2_14___otp_broadcast_o_reg_secret_prod_partition_2_data_cptra_core_field_entropy_2_13___otp_broadcast_o_reg_secret_prod_partition_2_data_cptra_core_field_entropy_2_12_
... (and so on)
So would caliptra_ss_top/u_otp_ctrl/*otp_broadcast_o*reg* be the correct exclusion regex here?
As for the cipher keys it does not mention which exact parameter in otp_ctrl_part_pkg.sv it is. I assume it is referring to "RndCnstKey" (SEC_CM: SECRET.MEM.SCRAMBLE)?
The signal driven by this constant is "caliptra_ss_top/u_otp_ctrl/u_otp_ctrl_scrmbl/rnd_cnst_key_anchor" before it goes into various combo logic and a large fanout. Tracing a few paths I ended up with something like:
caliptra_ss_top/u_otp_ctrl/u_otp_ctrl_scrmbl/MBF_key_state_q_reg_79___key_state_q_reg_78___key_state_q_reg_77___key_state_q_reg_76___key_state_q_reg_75___key_state_q_reg_74___key_state_q_reg_73___key_state_q_reg_72_
For this I could use a regex such as: caliptra_ss_top/u_otp_ctrl/u_otp_ctrl_scrmbl/*key_state*reg*
Is this the correct regex to use? Are there any others?
Finally the raw unlock token: Here the integration spec mentions to exclude "caliptra_ss_top/u_lc_ctrl/u_lc_ctrl_fsm/hashed_token_mux*" and "caliptra_ss_top/u_lc_ctrl/lc_ctrl_fsm/hashed_tokens*", but neither of these are scannable flops. In fact the spec itself mentions " it is stored in the plaintext in gates". Since these are gates, how is scan (or scan exclusions) supposed to work? For now we are not adding any exclusion for these two, as there are no flops involved in the signals mentioned above. Our logic outside that is driving this input to Caliptra does not involve any flops either (its a constant).
Also: There is a set of digest registers for secret partitions, but there are no instructions for excluding them. I was wondering if maybe they would be good to exclude as well:
caliptra_ss_top/u_otp_ctrl/u_reg_core/u_secret_lc_transition_partition_digest_*
caliptra_ss_top/u_otp_ctrl/u_reg_core/u_secret_manuf_partition_digest_*
caliptra_ss_top/u_otp_ctrl/u_reg_core/u_secret_prod_partition_*_digest_*
Please let me know if you have any questions or need me to trace other paths for these signals. I want to make sure I get these scan exclusions right.
Best Regards,
Nicolas