Signed UAV tracking

Overall goal

Certify the responsible person of any received UAV position.

Constraints

  • 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

Principles

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".

Main schema

Signing schema

  1. Authentication against a user authentication service which provides strong identity verification (like FranceConnect)
  2. An Oauth token is sent back to the user
  3. The user sends this token with the registration number and the public key of the device
  4. The token is verified against the authentication service
  5. An encrypted secret is sent back to the user
  6. That token is securely transfered to the Unmanned Aerial Vehicle (UAV) which will be able to emit signed positions
  7. The UAV emits a signed position toward the position storage, the payload is signed using the secret previously transmitted
  8. Once the position storage receives a position, it checks the signature against the certification registry
  9. Which validates or not the integrity of the position.

Steps 1 to 6 are only done once and for all.

Provisioning

This is the stage where a public key is associated with a device (in the form of its identification number).

Workflow

  • 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

Abstract flow

sequenceDiagram participant D as Device participant R as Registry API D-->>R: Authenticates with OAuth D->>+R: Sends public key via HTTPS Note right of R: Server generates a unique secret and encrypt it with the public key R->>-D: Returns encrypted secret

Factory provisioning flow

sequenceDiagram participant D as Device participant F as Factory Server participant R as Registry API Note over F: Generates private and public keys F-->>R: Authenticates with OAuth client credentials grant F->>+R: Sends public key via HTTPS Note right of R: Server generates a unique secret and encrypt it with the public key R->>F: Returns encrypted secret key F->>D: Secret key provisioning (offline)

Owner provisioning flow

sequenceDiagram participant FC as FranceConnect participant O as Owner with Device participant R as Registry API Note over O: Generates private and public keys O-->>R: Authenticates with OAuth authorization code grant R-->>FC: Delegates final auth to FranceConnect FC->>O: Authenticates O->>+R: Sends public key via HTTPS Note right of R: Server generates a unique secret and encrypt it with the public key R->>O: Returns encrypted secret key

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

Risks

  • 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

Remarks

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).

Commissioning

This is the stage where a human person is associated with a device. The need is to certify the identity of the human person.

Workflow

  • the human person authenticates herself to the registration portal with FranceConnect
  • the human person indicates the device identification numbers they own
sequenceDiagram participant ID as Identity Provider participant O as Owner participant R as Registration API O-->>R: Registers R-->>ID: Delegates final auth ID->>O: Authenticates Note over O,R: Creates account

Risks

  • if some FranceConnect credentials are compromised, the devices must be revoked

Data transmission

This is the stage where a device sends its position. The need is to certify the authenticity and the integrity of the received data.

Workflow

  • 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
sequenceDiagram participant D as Device participant P as Positions API participant Rid as Registration API participant Rg as Registry API D-->>P: Sends payload signed with secret P-->>Rid: Checks device is commissionned P-->>Rg: Checks payload is signed with correct key Note over P: Save position as valid

Accepted risks

  • it's accepted that the data is sent in clear

Revocation

This is the stage where a device is dismissed from the network.

Workflow

  • the device is marked as revoked in the database

Re-keying

This is the stage where a device has been revoked and want to join back the network.

Workflow

  • the provisioning and commissioning must be started back from the beginning
  • a non revoked device cannot be reset

FAQ

  • Why not using secure boot? We don't control (nor want to) the industrial process of bootstrapping chips

References