Encryption

[podhrmic]

Encryption

The encryption is optional and does not depend on the scheduling described above. The encryption scheme is based on Galois Embedded Crypto and involves 16 bytes of overhead after the initial key exchange.

The encrypted pprz message v1.0 looks like this (see wiki for more details):

PPRZ-message: ABCxxxxxxxDE
    A PPRZ_STX (0x99)
    B LENGTH (A->E)
    C PPRZ_DATA
      0-3 COUNTER
      // ciphertext start
      4 SENDER_ID
      5 MSG_ID
      6 MSG_PAYLOAD
      . DATA (messages.xml)
      // ciphertext end
      7-18 TAG (12 bytes)
    D PPRZ_CHECKSUM_A (sum[B->C])
    E PPRZ_CHECKSUM_B (sum[ck_a])```

and v2.0 like this:

PPRZ-message: ABCxxxxxxxDE
    A PPRZ_STX (0x99)
    B LENGTH (A->E)
    C PPRZ_DATA
      0 SOURCE (~sender_ID)
      1 DESTINATION (can be a broadcast ID)
      2-5 COUNTER (4 bytes)
      // ciphertext start
      6 CLASS/COMPONENT
        bits 0-3: 16 class ID available
        bits 4-7: 16 component ID available
      7 MSG_PAYLOAD
      . DATA (messages.xml)
      // ciphertext end
      8-19 TAG (12 bytes)
    D PPRZ_CHECKSUM_A (sum[B->C])
    E PPRZ_CHECKSUM_B (sum[ck_a])

Messages

And we indeed need to define new messages for the key exchange:

Telemetry class:

    <message name="KEY_EXCHANGE_UAV" id="254">
      <description>Message for key exchange during crypto initialization</description>
      <field name="type" type="uint8" values="P_AE|P_BE|SIG"/>
      <field name="data" type="uint8[]"/>
    </message>

Datalink class:

    <message name="KEY_EXCHANGE_GCS" id="159">
      <description>Message for key exchange during crypto initialization</description>
      <field name="type" type="uint8" values="P_AE|P_BE|SIG"/>
      <field name="data" type="uint8[]"/>
    </message>

Implementation

The generated code needs to know when to insert the extra counter and tag, but we might be able to change/modify the message generators and then handle d/encryption in the autopilot code.

Other option is to include crypto inside pprzlink and have some sort of state machine to keep track of it.

Because everything until DlCheckAndParse() is the same, we need to (tentatively):

• [ ] add crypto mode into paparazzi (integrate code from here)
• [ ] make the crypto module automatically loadable depending on the settings (CRYPTO ON/OFF)
• [ ] change DlCheckAndParse to handle encryption and key exchange
• [ ] modify generated pprzlink messages to include encrypted data (add counter and a tag, the encryption will be handled by the paparazzi code)
• [ ] modify pprzlink parsers to support encrypted messages (that should be easy)
• [ ] add encryption into send_msg_XXX functions (either weak link against paparazzi code, or include crypto
• [ ] handle key exchange cases in pprzlink generated code

[podhrmic]

The crypto should be a part of pprzlink

A good way to do it would be to make a no-std version of a crypto-lib, and then either link it with the pprzlink for embedded application, or have it as a rust crate in rustlink.