Debug Authentication Respone LPC55Sxx

[GrzegorzM]

Hello,

I am having a problem with debug authentication on my LPC55S14 chip.
In the LPC55S1x/LPC551x User Manual (UM11295), section 51.7.4 describes Debug Authentication Response. I have a question regarding this. How to calculate the SIG?
I have a file with DCKpriv, DAR::DC, DAR::AB and DAC::CV (I know that the vector is changing.), but I don't understand this equation.
SIG = RSA_SIGN (DCKpriv,SHA256(DAR::DC II DAR::AB II DAR::CV))
Can you explain how this is calculated?
I cannot use CMSIS-DAP or the J-Link debugger (as described in Debug Authenticaton (AN13037)).
Thanks
Grzegorz 

[diego_charles]

Hi @GrzegorzM 

I hope that you are doing excellent. My apologies for the late reply!

I also see that UM provides a pseudocode for the RSA signature equation (SIG). Which is similar to the below MBEDTLS function :

/**
 * \brief          This function performs a PKCS#1 v1.5 signature
 *                 operation (RSASSA-PKCS1-v1_5-SIGN).
 * \deprecated     It is deprecated and discouraged to call this function
 *                 in #MBEDTLS_RSA_PUBLIC mode. Future versions of the library
 *                 are likely to remove the \p mode argument and have it
 *                 implicitly set to #MBEDTLS_RSA_PRIVATE.
 *
 * \note           Alternative implementations of RSA need not support
 *                 mode being set to #MBEDTLS_RSA_PUBLIC and might instead
 *                 return #MBEDTLS_ERR_PLATFORM_FEATURE_UNSUPPORTED.
 *
 * \param ctx      The initialized RSA context to use.
 * \param f_rng    The RNG function. If \p mode is #MBEDTLS_RSA_PRIVATE,
 *                 this is used for blinding and should be provided; see
 *                 mbedtls_rsa_private() for more. If \p mode is
 *                 #MBEDTLS_RSA_PUBLIC, it is ignored.
 * \param p_rng    The RNG context to be passed to \p f_rng. This may be \c NULL
 *                 if \p f_rng is \c NULL or doesn't need a context argument.
 * \param mode     The mode of operation. This must be either
 *                 #MBEDTLS_RSA_PRIVATE or #MBEDTLS_RSA_PUBLIC (deprecated).
 * \param md_alg   The message-digest algorithm used to hash the original data.
 *                 Use #MBEDTLS_MD_NONE for signing raw data.
 * \param hashlen  The length of the message digest.
 *                 Ths is only used if \p md_alg is #MBEDTLS_MD_NONE.
 * \param hash     The buffer holding the message digest or raw data.
 *                 If \p md_alg is #MBEDTLS_MD_NONE, this must be a readable
 *                 buffer of length \p hashlen Bytes. If \p md_alg is not
 *                 #MBEDTLS_MD_NONE, it must be a readable buffer of length
 *                 the size of the hash corresponding to \p md_alg.
 * \param sig      The buffer to hold the signature. This must be a writable
 *                 buffer of length \c ctx->len Bytes. For example, \c 256 Bytes
 *                 for an 2048-bit RSA modulus. A buffer length of
 *                 #MBEDTLS_MPI_MAX_SIZE is always safe.
 *
 * \return         \c 0 if the signing operation was successful.
 * \return         An \c MBEDTLS_ERR_RSA_XXX error code on failure.
 */
int mbedtls_rsa_rsassa_pkcs1_v15_sign( mbedtls_rsa_context *ctx,
                               int (*f_rng)(void *, unsigned char *, size_t),
                               void *p_rng,
                               int mode,
                               mbedtls_md_type_t md_alg,
                               unsigned int hashlen,
                               const unsigned char *hash,
                               unsigned char *sig );

Are you developing a custom debugger solution? Let me know if there is something else where we may help.

Diego

[GrzegorzM]

Hi,

Thank you for your reply.
I have one more question. I am using MCUXpresso Secure Provisioning to create certificates and sign images. I am using the following keys when creating the image: ROT1: IMG1_1. How do I need to configure the config.yml file for such matched keys?

Currently I have following configuration and it does not work:
socc: 0x00000001
uuid: "00000000000000000000000000000000"
cc_socu: 0x03FF
cc_vu: 0x0000
cc_beacon: 0x0
rot_id: 0x0
rot_meta:
- ...\keys\ROT1_sha256_2048_65537_v3_ca_key.pub
- ...\keys\ROT2_sha256_2048_65537_v3_ca_key.pub
- ...\keys\ROT3_sha256_2048_65537_v3_ca_key.pub
- ...\keys\ROT4_sha256_2048_65537_v3_ca_key.pub
rotk: ...\keys\IMG1_1_sha256_2048_65537_v3_usr_key.pem
dck: ...\keys\rotk0_rsa_2048.pub

When I use the ROT1 key with the following configuration, everything works fine.
socc: 0x00000001
uuid: "00000000000000000000000000000000"
cc_socu: 0x03FF
cc_vu: 0x0000
cc_beacon: 0x0
rot_id: 0x0
rot_meta:
- ...\keys\ROT1_sha256_2048_65537_v3_ca_key.pub
- ...\keys\ROT2_sha256_2048_65537_v3_ca_key.pub
- ...\keys\ROT3_sha256_2048_65537_v3_ca_key.pub
- ...\keys\ROT4_sha256_2048_65537_v3_ca_key.pub
rotk: ...\keys\ROT1_sha256_2048_65537_v3_ca_key.pem
dck: ...\keys\rotk0_rsa_2048.pub

Thanks
Grzegorz 

[diego_charles · Accepted solution]

Hi @GrzegorzM 

Glad to reply!

I think that the IMG1_1_sha256_2048_65537_v3_usr_key.pem does not form part of the ROT keys embedded into the MCU.

I think that  you might have used a similar command to generate the cmpa.bin 

pfr generate-binary -c cmpa_config.yml -i -f keys\rot0_2048.pub -f keys\rot1_2048.pub -f keys\rot2_2048.pub -f keys\rot3_2048.pub -o cmpa.bin

Therefore the  ROT1_sha256_2048_65537_v3_ca_key.pem (rot0_2048.pub in my above command) was embedded with the other ROT keys into CMPA bin. Then you should have flashed the CMPA.bin. So if ROT Key specified in the config.yml does not match with the ROT key flashed into CMPA the debug authentication will fail. 

Otherwise, let me know further about your issue.

Diego