Skip to main content

7.6 Reading encrypted recordings

A device with a recording key bound writes every recording to the SD card as ciphertext. The key model, how it is set up, and who holds the key are in 12. Recording encryption. This page is only about reading the files back.

What an encrypted recording looks like​

  • File names, part sizes and the directory layout are unchanged — still .mcap.
  • The content is ciphertext. A tool without the key errors out rather than reading garbage.
  • read_mcap supports random access without decrypting the entire file. Foxglove needs a plaintext copy generated with visio-decrypt before playback.
  • session.json fills recording_key_fingerprint (16 hex characters; empty when unencrypted) naming which key opens the files. It is a fingerprint, not the key, and can be distributed with the files.

Three ways to read​

Once the key is in your local keychain, day-to-day use is identical to unencrypted recordings — you don't pass the key each time.

# 1) Pass the key file explicitly
visio-display --mcap-in ego_0000.mcap --key-file recording.key --rerun

# 2) Or keep keys in the local keychain file, indexed by fingerprint
#    (several teams' keys can live side by side)
#    ~/.config/visio/recording-keys.json

# 3) For tools that can't take a key (e.g. Foxglove Studio), write a plaintext copy
visio-decrypt ego_0000.mcap ego_0000_plain.mcap

visio-display --serve also stores keys into the keychain when you set them on a device, so an admin who provisioned the fleet from their own machine already has what they need.

In Python​

read_mcap automatically loads keys from ~/.config/visio/recording-keys.json or the file specified by VISIO_RECORDING_KEY_FILE; a separate decryption pass is not required for Python. Tools that cannot accept keys, such as Foxglove, still need a plaintext copy.

A lost key is lost data

Encrypted recordings have no back door, and GI Labs cannot recover them. Back the key file up in at least two places, kept apart from the devices.