Add encrytion option to rosbag

[yathartha3]

Description

As a rosbag2 user, I would like to encrypt the messages when I am recording the bag files. The encryption should happen while recording, as opposed to post-processing.

Completion Criteria

• rosbag record has an option to encrypt messages
• rosbag play has an option to decrypt messages
• rosbag record can get the keys (for example GPG keys from user name, or from a file location) for encryption
• messages in the rosbag is encrypted, as opposed to the final rosbag file. such that if the recording node dies, the messages are still encrypted

Implementation Notes / Suggestions

• be able to read GPG keys from the system
• be able to read keys from a file
• use OpenSSL, and provide a few encryption options. (ROS1 had AES encrption as an option)

[emersonknapp]

Noting related to #1285

Just some design questions to try and think about this feature (no conclusions) -

• Would it be of higher value to consider this on a system level rather than recording level? For example perhaps in https://github.com/ros2/sros2 - some way to send traffic encrypted in the first place, then we figure a way to just have rosbag2 receive and record the encrypted traffic without touching it either for recording or playback.
• What's a concrete use case to help inform the design?
• What information is allowed to be present in the bag unencrypted? Topic name, topic type, topic schema? Message contents would of course be encrypted, but would this other information be considered sensitive?
• If metadata is not sensitive, then perhaps a simple transformer plugin location for RecorderImpl::create_subscription that somehow munges an rclcpp::SerializedMessage binary data before passing it on to the Writer implementation.
• Otherwise if metadata is sensitive, then this probably requires a much more thorough pass on what an "encrypted mcap" for example would look like.

[MichaelOrlov]

@emersonknapp I am curious if one would be possible to use rosbag2 conversion plugin interface https://github.com/ros2/rosbag2/blob/rolling/docs/converter_plugin_development.md to write encription/decription plugin without any changes in the rosbag2 core? At least as a quick workaround.

[yathartha3]

@emersonknapp

* Would it be of higher value to consider this on a system level rather than recording level? For example perhaps in https://github.com/ros2/sros2 - some way to send traffic encrypted in the first place, then we figure a way to just have rosbag2 receive and record the encrypted traffic without touching it either for recording or playback.

The use case I am thinking is for storage of Personally Identifiable Information (PII). So, for this purpose encrypting the traffic is unnecessary. I am only thinking about storage (and not transport).

* What's a concrete use case to help inform the design?

The use case I am thinking is for storage of Personally Identifiable Information (PII). So that would include any location data and anything that could perceive the driver (cameras, LiDARs, etc.) We run human-robot experiments, for which the data needs to be stored encrypted. While collecting real world data in the wild, the robot(vehicle) can be recording participant's data for prolonged duration of time (months) before we are able to upload it to storage.

* What information is allowed to be present in the bag unencrypted? Topic name, topic type, topic schema? Message contents would of course be encrypted, but would this other information be considered sensitive?

Topic name, topic type, topic schema are fine to be unencrypted. Initially, I thought about encrypting the headers as well, but it seems unnecessary.

[chaoflow]

@yathartha3 Do you actually need partially encrypted files or would an encrypted filesystem also fulfill GDPR requirements?

[yathartha3]

@yathartha3 Do you actually need partially encrypted files or would an encrypted filesystem also fulfill GDPR requirements?

@chaoflow
When you say "partially encrypted files", I am assuming that you are referring to a rosbag file with encrypted message data, but the topic names, and some header information is readable (as long as it does not have any PII).

In a real world use case where experiments (data collection) can run for months, there is a risk that if for some reason the recording node fails, or system power is interrupted before the bag files are properly closed/written, the data will be un-encrypted since it will never get to the point where it encrypts the file after the recording is complete. So in this case, even-though encrypting the filesystem would have fulfilled the GDPR requirements, it might not get to the stage of encrypting the files.
Also, encrypting the file-system would probably be outside the scope for rosbag2.

Please let me know if my suggestion does not make sense.