# Offline enrollment scenario
TIP!
Please read the overview article for the general approach to device enrollment.
In some cases during the manufacturing phase, the enrollment initiated by direct communication between the device and the RA server is inefficient. This might include the process of manufacturing NB-IoT devices. It doesn't mean though that a device is not able to be enrolled in the Ability PKI.
# The enrollment process steps.
- Generate the RSA key pair on the secure element (mostly TPM 2.0).
- Create the CSR containing the enrollment code and the requested certificate fields.
- Send the CSR to the RA endpoint using the SCEP protocol.
- Place the certificate on the device.
The asymmetric nature of the RSA cryptography allows for the process design in which some steps can take place on a different machine still providing the security of the mechanism. Reading through the steps it is obvious that the key pair has to be generated on the device itself due to the requirement of generating the key pair on the security chip. Signing the CSR is restricted in the same way for similar reason (only the security chip can perform the sign operation). Sending the CSR to the RA endpoint is not limited in this way though. The CSR can be moved to a machine that is capable of communication with the Server's RA endpoint through the SCEP protocol. The issued certificate can be placed back on the device thus completing the process.
# DPCM configuration for offline enrollment
DPCM - the Ability Edge component responsible for certificate enrollment and
registration, is capable of operating in the offline mode. There is a separate
article that describes the edge setup in
general. For the offline enrollment use case, there are some specific parameters
that have to be set in the /etc/dpcm.config
file. These are:
REGISTER_DEV_ID=0
- Flag disabling the call to the Global ID Generator (GIG) service after successful enrollment to register the DeviceID/ObjectID/CNOFFLINE_ENROLLMENT=1
- Flag that triggers the Offline Enrollment modeDEVICEID_DUPLCATION_CHECK_REQUIRED=0
- Flag that disables the call to the GIG to check for uniqueness of the Device ID
After running DPCM configured in that way, the file CSR.der
is produced in
/var/ability/certs
. It has to be transferred to a machine that is capable of
sending the request to the SCEP endpoint of the Ability PKI RA server. For this
purpose a tool described in the Certificate Enrollment With SCEP can be used.
Finally the obtained certificate has to be transferred back to the device and
placed in the /var/ability/certs
directory.