Personalization
In order to evaluate the device in this use case it first needs to be configured for this use case, this is done during the personalization phase. See the OPTIGA™ Authenticate NBT Static Connection Handover Use Case Guide for more information about the general procedure.
The personalization can only be performed via I2C. For the evaluation of this use case, there exists an example configuration (see Target configuration). The NBT Static Connection Handover embedded application can be used to personalize the device for the SCH evaluation.
System architecture
This section shows the system architecture for the personalization.
Hardware
For personalization via I2C, the development shield needs to be attached to the pre-soldered pin sockets of the host MCU board. This connects the power supply (3V3, GND) and the I2C pins (SDA, SCL). Even tough the IRQ pin is connected, it is not actively utilized in this use case’s example applications.
Fig. 105 Hardware components for personalization via I2C.
Software
The NBT Static Connection Handover embedded application can also be used to personalize the device via I2C. This application does a personalization routine during its initialization phase, before the operational loop is started.
Fig. 106 Software architecture of the included applications for the personalization via I2C.
The NBT Static Connection Handover embedded application is shared as source code and contains the personalization logic. The applications running on the OPTIGA Authenticate NBT are considered on-chip software, pre-flashed to the device and not alterable.
The personalization flow utilizes the Configurator applicaiton and the Type 4 Tag application of the OPTIGA™ Authenticate NBT’s on-chip applications. Refer to the extended datasheet for more information about the on-chip applications.
Personalization flow
The NBT Personalization mobile phone app personalizes the device via NFC.
Fig. 107 Flow diagram for personalizing the OPTIGA™ Authenticate NBT for this example application.
The mobile phone app sets the device to a pseudo default state before performing the use-case-specific personalization. During this step, the NDEF file’s content is cleared and the file access policies are set to the default values. The content of the proprietary files is not touched.
Target configuration
Describes which settings of the OPTIGA™ Authenticate NBT are altered during the personalization phase (based on the device’s default state).
T4T file access policy
File |
I2C_Read |
I2C_Update |
NFC_Read |
NFC_Update |
|---|---|---|---|---|
FAP_FILE |
✓ |
✓ |
✓ |
✓ |
CC_FILE |
✓ |
✗ |
✓ |
✗ |
NDEF_FILE |
✓ |
✓ |
✓ |
✗ |
PP1_FILE |
✗ |
✗ |
✗ |
✗ |
PP2_FILE |
✗ |
✗ |
✗ |
✗ |
PP3_FILE |
✗ |
✗ |
✗ |
✗ |
PP4_FILE |
✗ |
✗ |
✗ |
✗ |
The CC_FILE is updated accordingly to reflect the permission settings. In order to allow this operation the permission to update the CC_FILE needs to be temporary granted.
Interface settings
Interface |
Setting |
|---|---|
I2C |
Enabled |
NFC |
Enabled |
IRQ function |
Disabled |
NDEF file content
The NDEF_FILE is written by the embedded application amd contains an NDEF message, consisting of a connection handover NDEF record. This record contains device-specific information to allow a mobile phone to establish a BLE connection with the PSoC™ host MCU board (e.g., Bluetooth® LE MAC address).