Hardware DES in PSOC62

For some reasons, support of DES SCA was completely dropped from the CW.

If I correctly remember, there were no attempts to add hardware DES. SCA attacks against hardware DES I found pretty interesting as:

  1. Leakage models are applicable very well to DES.
  2. Move from well known AES attacks to something new which can be implemented from very beginning.

So, I decided to use the PSOC62 SoC which has a rich set of HW crypto algorithms.

Writing the DES app was pretty straightforward, the little challenge was flashing the firmware using J-link. Infineon artificially enforces using its KitProg3 tool via the OpenOCD code.

To bypass it, I did a hack stored at jlink_psoc62_swd.cfg

source [find interface/jlink.cfg]
transport select swd
adapter speed 1000

# Override acquisition to work with J-Link
proc mxs40_acquire { target } {
    echo "J-Link: Skipping acquisition (not needed/supported)"
    return 1  # Return success to continue
}

# Source the original config
source [find target/infineon/cy8c6xx.cfg]

# Override the broken function
proc mxs40_reset_deassert_post { target_type target } {
    echo "J-Link: Simplified reset for PSoC62"
    
    # Skip KitProg3 acquisition check
    if {[string match "psoc6*" $target_type]} {
        # Just do basic reset, no acquisition
        psoc6 reset_halt sysresetreq
    }
}

init
reset init

echo "PSoC62 ready for programming with J-Link"

To burn the firmware via SWD and using J link, it is necessary to download Infineon OpenOCD go to its bin folder and then run openocd -f ../jlink_psoc62_swd.cfg.

Then run telnet localhost 4444 in another console and burn the firmware from there

flash write_image erase /Users/username/simpleserial-des/simpleserial-des-CW308_PSOC62.hex

reset run

the expected output is

auto erase enabled
Flash write discontinued at 0x10008270, next section at 0x1000a000
Padding image section 0 at 0x10008270 with 400 bytes (bank write end alignment)
[100%] [################################] [ Erasing     ]
[100%] [################################] [ Programming ]
Padding image section 1 at 0x1000dba4 with 92 bytes (bank write end alignment)
[100%] [################################] [ Erasing     ]
[100%] [################################] [ Programming ]
wrote 49152 bytes from file /Users/username/simpleserial-des/simpleserial-des-CW308_PSOC62.hex in 1.061066s (45.238 KiB/s)

I think it worth to highlight it, as this can be a real limitation of using the target board based on PSOC62.

The DES power traces I captured:

  1. Complete traces:

  1. Zoomed in:

Next steps are write the leak models and scan the whole range for potential leakages to run the CPA attack there.

Have you tried using pyOCD instead?

It seems to already have built-in support for a whole bunch of MCUs from this family:

$ pyocd list --target | grep cy8c6
  cy8c64_sysap              Cypress                  cy8c64_sysap                                             builtin  
  cy8c64x5_cm0              Cypress                  cy8c64x5_cm0                                             builtin  
  cy8c64x5_cm0_full_flash   Cypress                  cy8c64x5_cm0_full_flash                                  builtin  
  cy8c64x5_cm4              Cypress                  cy8c64x5_cm4                                             builtin  
  cy8c64x5_cm4_full_flash   Cypress                  cy8c64x5_cm4_full_flash                                  builtin  
  cy8c64xa_cm0              Cypress                  cy8c64xA_cm0                                             builtin  
  cy8c64xa_cm0_full_flash   Cypress                  cy8c64xA_cm0_full_flash                                  builtin  
  cy8c64xa_cm4              Cypress                  cy8c64xA_cm4                                             builtin  
  cy8c64xa_cm4_full_flash   Cypress                  cy8c64xA_cm4_full_flash                                  builtin  
  cy8c64xx_cm0              Cypress                  cy8c64xx_cm0                                             builtin  
  cy8c64xx_cm0_full_flash   Cypress                  cy8c64xx_cm0_full_flash                                  builtin  
  cy8c64xx_cm0_nosmif       Cypress                  cy8c64xx_cm0_nosmif                                      builtin  
  cy8c64xx_cm0_s25hx512t    Cypress                  cy8c64xx_cm0_s25hx512t                                   builtin  
  cy8c64xx_cm4              Cypress                  cy8c64xx_cm4                                             builtin  
  cy8c64xx_cm4_full_flash   Cypress                  cy8c64xx_cm4_full_flash                                  builtin  
  cy8c64xx_cm4_nosmif       Cypress                  cy8c64xx_cm4_nosmif                                      builtin  
  cy8c64xx_cm4_s25hx512t    Cypress                  cy8c64xx_cm4_s25hx512t                                   builtin  
  cy8c6xx5                  Cypress                  CY8C6xx5                                                 builtin  
  cy8c6xx7                  Cypress                  CY8C6xx7                                                 builtin  
  cy8c6xx7_nosmif           Cypress                  CY8C6xx7_nosmif                                          builtin  
  cy8c6xx7_s25fs512s        Cypress                  CY8C6xx7_S25FS512S                                       builtin  
  cy8c6xxa                  Cypress                  CY8C6xxA                                                 builtin  

For ARM-based targets, that has been my preferred way to flash over openocd.

No yet. Thanks, good to know!

First results look promising. Same, as in AES, Pearson correlation is negative. Strong leakage happens before Sbox in.

And here is the rank of all subkeys

0x00 and 0x3F are complementary, hence they have the same correlation value. But as PSOC62 has negative correlation for the correct subkey, 0x3F can be rejected.

Top 10 Key Guesses (by |correlation|):
 Rank | Key (hex) | Correlation | |Correlation|
---------------------------------------------
   1. |   0x00    | -0.198042 | 0.198042
   2. |   0x3F    |  0.198042 | 0.198042
   3. |   0x01    | -0.197494 | 0.197494
   4. |   0x3E    |  0.197494 | 0.197494
   5. |   0x1F    |  0.187288 | 0.187288
   6. |   0x20    | -0.187288 | 0.187288
   7. |   0x1E    |  0.187029 | 0.187029
   8. |   0x21    | -0.187029 | 0.187029
   9. |   0x08    | -0.128866 | 0.128866
  10. |   0x37    |  0.128866 | 0.128866

The interesting thing, the DES itself almost at the end of the trace? But what is before? DES key schedule? But it shouldn’t be so long.