- Forums
- Product Forums
- General Purpose MicrocontrollersGeneral Purpose Microcontrollers
- i.MX Forumsi.MX Forums
- QorIQ Processing PlatformsQorIQ Processing Platforms
- Identification and SecurityIdentification and Security
- Power ManagementPower Management
- Wireless ConnectivityWireless Connectivity
- RFID / NFCRFID / NFC
- Advanced AnalogAdvanced Analog
- Neural Processing UnitsNeural Processing Units
- MCX Microcontrollers
- S32G
- S32K
- S32V
- MPC5xxx
- Other NXP Products
- S12 / MagniV Microcontrollers
- Powertrain and Electrification Analog Drivers
- Sensors
- Vybrid Processors
- Digital Signal Controllers
- 8-bit Microcontrollers
- ColdFire/68K Microcontrollers and Processors
- PowerQUICC Processors
- OSBDM and TBDML
- S32M
- S32Z/E
-
- Solution Forums
- Software Forums
- MCUXpresso Software and ToolsMCUXpresso Software and Tools
- CodeWarriorCodeWarrior
- MQX Software SolutionsMQX Software Solutions
- Model-Based Design Toolbox (MBDT)Model-Based Design Toolbox (MBDT)
- FreeMASTER
- eIQ Machine Learning Software
- Embedded Software and Tools Clinic
- S32 SDK
- S32 Design Studio
- GUI Guider
- Zephyr Project
- Voice Technology
- Application Software Packs
- Secure Provisioning SDK (SPSDK)
- Processor Expert Software
- Generative AI & LLMs
-
- Topics
- Mobile Robotics - Drones and RoversMobile Robotics - Drones and Rovers
- NXP Training ContentNXP Training Content
- University ProgramsUniversity Programs
- Rapid IoT
- NXP Designs
- SafeAssure-Community
- OSS Security & Maintenance
- Using Our Community
-
- Cloud Lab Forums
-
- Knowledge Bases
- ARM Microcontrollers
- i.MX Processors
- Identification and Security
- Model-Based Design Toolbox (MBDT)
- QorIQ Processing Platforms
- S32 Automotive Processing Platform
- Wireless Connectivity
- CodeWarrior
- MCUXpresso Suite of Software and Tools
- MQX Software Solutions
- RFID / NFC
- Advanced Analog
- Neural Processing Units
-
- NXP Tech Blogs
- Home
- :
- Translated Content
- :
- Multi Source Translation Content
- :
- 2414836_en-US
2414836_en-US
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
2414836_en-US
2414836_en-US
Hello NXP,
Thank you as always for your support.
Based on your previous response regarding our FBL-related inquiry, we understood that when the Life-Cycle is in the In-Field state, either the MASTER_ECU_KEY or a CUST/OEM authorization key must have been provisioned in advance in order to obtain SuperUser (SU) authority, and that provisioning the MASTER_ECU_KEY is not possible once the device is already in the In-Field state.
Could you please confirm whether our understanding is correct?
Currently, neither of these two keys has been provisioned. To prevent similar issues from occurring in the future, we would like to provision either the MASTER_ECU_KEY or a CUST/OEM authorization key in advance, so that we can format the NVM/RAM key catalog and inject the HMAC key after the device enters the In-Field state.
We have a few questions as follows:
1. In this project, FBL authentication is not based on SHE. Instead, it uses RSA public-key signature verification. However, CRYPTO_SPT_SHE is configured as STD_ON.
In this case, should we provision the MASTER_ECU_KEY, or should we provision a CUST/OEM authorization key?
2. Is there any guide or reference documentation that describes how to import the MASTER_ECU_KEY or a CUST/OEM authorization key?
Thank you.
Best regards,
Hi @jeongwoo
The authorization key should be provisioned according to the current lifecycle and the key owner you need to operate with.
In CUST_DEL, you can provision the CUST authorization key. Once you advance the device to OEM_PROD, you can provision the OEM authorization key and use it to obtain Super User rights for OEM-owned keys.
You cannot provision an OEM-owned key while still in CUST_DEL, because at that point you do not have an OEM authorization key that could authorize the operation. Therefore, the key catalogs for the required owners should already be defined while the device is in CUST_DEL, before advancing the lifecycle.
After moving to OEM_PROD, the catalogs cannot be reformatted, because key catalog formatting is restricted to CUST_DEL. This lifecycle transition is also irreversible.
So, if your intention is to have both CUST and OEM authorization capabilities, define the required CUST and OEM key groups in the catalogs first, provision the CUST authorization key in CUST_DEL, advance to OEM_PROD, and then provision the OEM authorization key.
You can take a look at this thread for details:
https://community.nxp.com/t5/S32K/Change-is-not-possible-in-LC-OEM-PROD/m-p/2356576
On HSE level, the key import procedure is described in section “6.2.3 Key Import” in HSE-B Firmware reference manual rev. 2.8 and then see the description of “struct hseImportKeySrv_t” in HSE Service API reference manual of your HSE firmware version.
On Autosar Crypto driver level, it is given by Autosar specification. You can read description of Crypto_43_HSE_KeyElementSet() and Crypto_43_HSE_KeySetValid() API in RTD_CRYPTO_43_HSE_UM.pdf.
Authorization keys are imported in the same way as other keys, it’s just necessary to set USAGE_AUTHORIZATION and USAGE_VERIFY key flags for that key in your configurator.
Regards,
Lukas