Signed UAV tracking
Certify the responsible person of any received UAV position.
- chips are slow, energy is precious: the lightest algorithm possible allowing to achieve the defined goal must be used
- data transmission is unidirectional (radio waves, UDP), key establishment must be done during provisioning
- acceptance matters: manufacturers, UAV owners, other countries
The trust chain lies on these three principles:
- we must be sure of the identity of the human person commissioning a given device
- we must be sure that the payload is sent by the device claiming to send it
- we must be sure of the device identity requesting bootstrapping
To be able to send data in the network, a device must fulfill the steps of provisioning and commissioning. This is also called "bootstrapping" or "onboarding".
- Authentication against a user authentication service which provides strong identity verification (like FranceConnect)
- An Oauth token is sent back to the user
- The user sends this token with the registration number and the public key of the device
- The token is verified against the authentication service
- An encrypted secret is sent back to the user
- That token is securely transfered to the Unmanned Aerial Vehicle (UAV) which will be able to emit signed positions
- The UAV emits a signed position toward the position storage, the payload is signed using the secret previously transmitted
- Once the position storage receives a position, it checks the signature against the certification registry
- Which validates or not the integrity of the position.
Steps 1 to 6 are only done once and for all.
This is the stage where a public key is associated with a device (in the form of its identification number).
- the device must generate an asymetric private and public RSA 512 key
- the device must be authenticated through OAuth
- the communication must be made through TLS
- the device send its public key to the server
- the server generates a unique symetric secret, and encrypt it with the public key
- the server send through TLS the unique AES key, plus a CRC checksum
- the device decrypt the payload and save the AES key for later use
Factory provisioning flow
Owner provisioning flow
OAuth grant types
- client credential: for manufacturers needing to batch register devices; those manufacturers needs to contact the service in order to create an OAuth client
- authorisation code: for one time device registration (for example a smartphone ground station): in this case, the person must be authenticated through FranceConnect
- if the device is compromised, the secret key is compromised, so the device must be revoked
- if some client credentials are compromised, the client must be deactivated, and most or all the device provisionned through this client must be revoked
- if the device database get compromised, it needs to be reset and all device needs bootstrapping again
This should ideally be done on the registration portal, so the authentication process will not be duplicated for the final UAV owner nor for the manufacturer (who will need to register in order to get their manufacturer id).
This is the stage where a human person is associated with a device. The need is to certify the identity of the human person.
- the human person authenticates herself to the registration portal with FranceConnect
- the human person indicates the device identification numbers they own
- if some FranceConnect credentials are compromised, the devices must be revoked
This is the stage where a device sends its position. The need is to certify the authenticity and the integrity of the received data.
- the device signs the payload with AES-CMAC using the secret key
- the server makes sure the device is owned
- the server verify the signature with the secret key
- it's accepted that the data is sent in clear
This is the stage where a device is dismissed from the network.
- the device is marked as revoked in the database
This is the stage where a device has been revoked and want to join back the network.
- the provisioning and commissioning must be started back from the beginning
- a non revoked device cannot be reset
- Why not using secure boot? We don't control (nor want to) the industrial process of bootstrapping chips