RT1046 DCP kDCP_OtpUniqueKey not working

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

RT1046 DCP kDCP_OtpUniqueKey not working

724 Views
ScottW_7
Contributor I

Hi NXP team,

        I used the RT1046 as the encryption operation unit for DCP, setting GPR10 to use the key from OCOTP (SW_GP2), and then programmed the key(sw_key) into SW_GP2.

        During testing, I found that the data encrypted with AES_ECB using kDCP_OtpKey and kDCP_OtpUniqueKey are identical, they also match the result when I directly use sw_key for AES_ECB encryption.

        According to the Reference Manual, kDCP_OtpUniqueKey should be independent and not the same as kDCP_OtpKey. Why is this happening?

Labels (1)
0 Kudos
Reply
1 Reply

684 Views
Bio_TICFSL
NXP TechSupport
NXP TechSupport

Hello,

The difference between kDCP_OtpKey and kDCP_OtpUniqueKey relates to how these keys are derived:

1. kDCP_OtpKey corresponds to the SW_GP2 key that you've programmed into the OCOTP fuses.

2. kDCP_OtpUniqueKey should be a device-unique key derived from the OTPMK (On-Time Programmable Master Key) and should produce different results than kDCP_OtpKey.

The reason you're seeing identical results is likely because your device is operating in an "open" (non-secure) configuration. In this configuration, the DCP doesn't generate true unique keys but instead uses standard values that may be identical across devices.

For kDCP_OtpUniqueKey to produce truly unique results different from kDCP_OtpKey, your RT1046 would need to be configured in a "secure closed" mode, where the OTPMK is properly utilized to create device-specific unique keys.

To verify this, check if you have properly configured the security settings, particularly SEC_CONFIG bits related to the OTPMK. Without proper security configuration, both key options will effectively use the same SW_GP2 value you programmed.

 
 
Regards
0 Kudos
Reply
%3CLINGO-SUB%20id%3D%22lingo-sub-2255890%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3ERT1046%20DCP%20kDCP_OtpUniqueKey%20not%20working%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2255890%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EHi%20NXP%20team%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%3CSPAN%3EI%20used%20the%20RT1046%20as%20the%20encryption%20operation%20unit%20for%20DCP%2C%20setting%20GPR10%20to%20use%20the%20key%20from%20OCOTP%20(SW_GP2)%2C%20and%20then%20programmed%20the%20key(sw_key)%20into%20SW_GP2.%20%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20During%20testing%2C%20I%20found%20that%20the%20data%20encrypted%20with%20AES_ECB%20using%20kDCP_OtpKey%20and%20kDCP_OtpUniqueKey%20are%20identical%2C%20they%20also%20match%20the%20result%20when%20I%20directly%20use%20sw_key%20for%20AES_ECB%20encryption.%20%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20According%20to%20the%20Reference%20Manual%2C%20kDCP_OtpUniqueKey%20should%20be%20independent%20and%20not%20the%20same%20as%20kDCP_OtpKey.%20Why%20is%20this%20happening%3F%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-2255890%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CLINGO-LABEL%3Ei.MXRT%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2256188%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%20translate%3D%22no%22%3ERe%3A%20RT1046%20DCP%20kDCP_OtpUniqueKey%20not%20working%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2256188%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EHello%2C%3C%2FP%3E%0A%3CDIV%20class%3D%22container%20slds-m-bottom_x-small%22%3E%0A%3CP%3EThe%20difference%20between%20kDCP_OtpKey%20and%20kDCP_OtpUniqueKey%20relates%20to%20how%20these%20keys%20are%20derived%3A%3CBR%20%2F%3E%3CBR%20%2F%3E1.%20kDCP_OtpKey%20corresponds%20to%20the%20SW_GP2%20key%20that%20you've%20programmed%20into%20the%20OCOTP%20fuses.%3CBR%20%2F%3E%3CBR%20%2F%3E2.%20kDCP_OtpUniqueKey%20should%20be%20a%20device-unique%20key%20derived%20from%20the%20OTPMK%20(On-Time%20Programmable%20Master%20Key)%20and%20should%20produce%20different%20results%20than%20kDCP_OtpKey.%3CBR%20%2F%3E%3CBR%20%2F%3EThe%20reason%20you're%20seeing%20identical%20results%20is%20likely%20because%20your%20device%20is%20operating%20in%20an%20%22open%22%20(non-secure)%20configuration.%20In%20this%20configuration%2C%20the%20DCP%20doesn't%20generate%20true%20unique%20keys%20but%20instead%20uses%20standard%20values%20that%20may%20be%20identical%20across%20devices.%3CBR%20%2F%3E%3CBR%20%2F%3EFor%20kDCP_OtpUniqueKey%20to%20produce%20truly%20unique%20results%20different%20from%20kDCP_OtpKey%2C%20your%20RT1046%20would%20need%20to%20be%20configured%20in%20a%20%22secure%20closed%22%20mode%2C%20where%20the%20OTPMK%20is%20properly%20utilized%20to%20create%20device-specific%20unique%20keys.%3CBR%20%2F%3E%3CBR%20%2F%3ETo%20verify%20this%2C%20check%20if%20you%20have%20properly%20configured%20the%20security%20settings%2C%20particularly%20SEC_CONFIG%20bits%20related%20to%20the%20OTPMK.%20Without%20proper%20security%20configuration%2C%20both%20key%20options%20will%20effectively%20use%20the%20same%20SW_GP2%20value%20you%20programmed.%3C%2FP%3E%0A%3C%2FDIV%3E%0A%3CDIV%20data-render-key%3D%221%22%3E%26nbsp%3B%3C%2FDIV%3E%0A%3CDIV%3E%0A%3CDIV%20class%3D%22section%20slds-grid%20slds-gutters_direct%20slds-wrap%22%3E%0A%3CDIV%20data-render-key%3D%221%22%3E%26nbsp%3B%3C%2FDIV%3E%0A%3CDIV%3E%0A%3CDIV%20class%3D%22slds-grid%20slds-wrap%20slds-gutters_direct%22%3ERegards%3C%2FDIV%3E%0A%3C%2FDIV%3E%0A%3C%2FDIV%3E%0A%3C%2FDIV%3E%3C%2FLINGO-BODY%3E