Black Block Recorder:
Immutable Black Box Logging
via rosbag2 and DLTs
By:

Ruﬃn White,
Gianluca Caiazza✉☑

✉☑

Motivation
With maturing R&D, robots have propagated into
many industries and economies, including
manufacturing, transport, logistics, and more.
As cyber-physical systems (CPS), the risks fromand threats to robots can surpass that incurredby conventional Internet of Things (IoT) devices.
Yet, are the methods used to monitor/audit such
CPS devices in pace with robotic proliferation?

2Motivation
Event Data Recorders (EDRs) in automotive, orBlack Box Flight recorders in aerospace industries
serve a multitude of critical directives, including:
●
●
●
●
●
●
●

3

Dataset & Model Acquisition
Performance Benchmarking
Quality Control and TestingContinuous Health Monitoring
Diagnostic Debugging & Triage
System Auditing & Verification
Digital Forensic Investigations

Motivation
With high-stake deployments come high-stake
consequences, thus the extraordinary incentives
evident to secure vs. circumvent EDR devices:●●●●

Hold liable parties accountable
Guide regulatory & legislative policy
VS.
Expunge incriminating evidence
Conspire to falsify historic events

Directive: to verify the integrity, authenticity, andcompleteness of robotic logs under the threat ofmalicious/erroneous insertion, or omission.
4

[1]Related Work●

[1] Jordi Cucurull, and Jordi Puiggalí. "Distributed
immutabilization of secure logs." International
Workshop on Security and Trust Management.
Springer, Cham, 2016.

●[2] Andrew Sutton, and Reza Samavi. "Blockchain
enabled privacy audit logs." International Semantic
Web Conference. Springer, Cham, 2017.

[2]5[3]Related Work●

[3] Sebastian Taurer, Bernhard Dieber, and Peter Schartner.
"Secure data recording and bio-inspired functional integrity for
intelligent robots." 2018 IEEE/RSJ International Conferenceon Intelligent Robots and Systems (IROS). IEEE, 2018.

●[4] Viktoras Kabir Veitas, and Simon Delaere. "In-vehicle data
recording, storage and access management in autonomousvehicles." arXiv preprint arXiv:1806.03243 (2018).

[4]6Constraints
CPSs such as commercially viable mobile robots
incur contains in addition to just cyber security:●

Limited energy capacity○○●

Build of Materials○○●

Event data recording must be continuous
Maximize data retention for auditability

Unreliable network connectivity○○

7

Practical costs and availability at scale
Consumer grade hardware compatible

Finite memory storage○○●Efficiency is key to prolong deployment
Minimize computational overhead

Uplink bandwidth a precious commodity
Flexible QoS to minimize overhead

Roles & Obligated Parties
●
●
●
●
●

8Custodian: Robot or autonomous vehicle OEM
Reporter: Trusted Logger or Recorder Enclave
Owner: End-User or Operator
Auditors: Regulatory Agencies or Gov.
Attacker: Malicious Actor

Party: Custodian✉ Data9Obligated subject of log content and tasked with log
preservation. e.g. Robot or autonomous vehicle OEM.

Robot

Party: ReporterEnclave🔒
10

An independent party responsible for faithfully recording
events. e.g. Trusted Logger or Recorder Enclave.

Robot🔓

Party: Owner

Mediating party that has a stake in ensuring log integrity,authenticity, confidentiality. e.g. End-User or Operator.

Plaant ?!

Data.
11

Party: Auditor
I’m watching
you, Dave.

12

Observing parties called upon to investigate and validate
record archives. e.g. Regulatory Agencies or Gov.

Party: Attacker

Noo, myData!

13

Any party intent on modifying the record to falsify events.
e.g. Malicious actor expunging incriminating evidence.

SS!!
SS
SiH!

Storage Requirements
1.

Data provision conditions○

2.

Fair and undistorted competition○3.

integrity and authenticity of logs must derivefrom an independent Reporter.

Data availability economy○

14

the co-location of logs external to that of the
Custodian must be prevented.

Tamper-proof access and liability○

5.

trust should be distributed and shared across allvalidators (a.k.a Custodians).

Data privacy and data protection○

4.

requires consent on behalf of the Owner whotransitively controls the log assets tracked.

health and transparency of logs are contingent
upon giving Auditors appropriate access.

System Properties
1.

Secure identification of physical data sources○2.

Metadata enrichment○

3.

reporting remains flexible in terms of QoS as well
as reasonable in resource consumption.

Access management○○

15

authenticated encryption is used in establishingsecure connectivity between parties.

Data recording & storage○

5.

log event context may be associated to respectiveOwner, Custodian and Reporter parties.

Data exchange and messaging○4.

attestation between devices trusted by theCustodian and Reporter.

rights, obligations, and authorization of parties
must be explicitly defined and enforceable.

Approach●

Introducing Black Block Recorder (BBR)●

To mediate separation of concerns, only
the recording process need be enclaved●

Enclaved process generates the logs by
capturing broadcasted message traffic●

Before streaming logs to arbitrary storage,
data must first be rendered immutable

EnclaveRecorder(Node)

LIDAR(Node)

LogStorage
16

Robot

Planner(Node)NonceApproach●Striding checkpoints are disseminated tothe a blockchain for eventual log auditing●

Checkpoints are comprised of cryptographic
linked integrity proofs that are indexed●Thus we explore EDRs based upon
Distributed Ledger Technology (DLT)

Topic Data

✉ Msg 1✉ Msg 2✉ Msg t17

HMAC

Checkpoint
Checkpoint
Checkpoint
Stamp:11
Stamp:
Stamp:
1...
Proof:...
Proof:
Proof: ☑

HMAC

Checkpoint
Checkpoint
Checkpoint
Stamp:11
Stamp:
Stamp:
2...
Proof:...
Proof:
Proof: ☑

HMAC

Checkpoint
Checkpoint
Checkpoint
Stamp:11
Stamp:
Stamp:t...
Proof:...
Proof:
Proof: ☑

Information Flow●

While a robot platform is held suspect, anenclave (e.g. TTE) is reserved for the reporter●Event data is received within the enclave via
SROS2 using authenticated encryption●

Linked integrity proofs for each asset tracked
are batched and signed via BBR rosbag plugin●

Batches are then signed within the enclave,then co-signed by the robot’s via BBR bridge●Thus an append-only forgery to DLT record
would necessitate the collusion of both thecustodian and its respective assigned reporter

18Onboard
ECU

SROS2 via
Secure DDS

Custodian
Robot 🔓Message: ✉Topic: /foo
Message:✉
Stamp:
Topic: /foot +1
Stamp: n +1

ROS2 Bag
DB 💾
Topics: 📄Name, Type
Messages:
Time, Data

SROS2

Transport

SQLitePluginSubject name:Recorder🔑…
X.509

RecorderEnclave 🔒CA

ECDSA
DigestEngineBBR Plugin

Checkpoint:
Stamp: t +1
Checkpoint:
Proof:... n +1
Stamp:

ROS2 BagBBR Sawtooth Bridge

Proof: ☑

Multicast
Subs

Subject name:
Robot
🔑…
X.509

CA

Transaction:
URI: /fooTransaction:
Payload: ...
URI: /foo
Payload: ...

SignatureValidator
Sawtooth 🔒Ledger
State 💾Batch:
URI: [/foo,/bar]
Payload: ...

SignatureRobot📶 #nMulticast
SubsAutomotive System

Robot
📶 #2

SROS2 via
Secure DDS

Swarm 📡Network

Robotic Sensor Network

Event Data ➔ Enclave ➔ ROS2 Bag Plugin ➔ Bridge ➔ DLT Validator ➔ DLT Network

Schema Structure●

Recorded event data is structured using
ROS2bag files and compatible SQLite schema●

Data insertions into the database are achieved
via 2D-array hash-chains of checkpoints●Where the primary axis checkpoints eachbagfile topic’s genesis-block and meta-info●

While the secondary axis checkpoints theinsertion of respective message data

●This coupling affords a holistic integrity proofof the entire database, while preserving topics
as a time series atomic, fostering parallelism

20Bagfile
Nonce

Bag💾
MetaInfo

Topic 1IDL Info
Msg: /foo
Stamp: 1
Data: ✉
Msg: /foo
Stamp: 2
Data: ✉

Topic 1
MetaInfo

Topic 2
MetaInfo

Namespace,Publisher,
Discovery...

Topic 2
Nonce

HMAC

Checkpnt
Stamp: 1
Proof: ☑

HMAC

Checkpnt
Stamp: 0
Proof: ☑

Topic Bagfile
Checkpnts ☑

Topic 1
NonceHMAC

Checkpnt
Stamp: 0
Proof: ☑

HMAC

Checkpnt
Stamp: 0
Proof: ☑

Topic 2IDL InfoHMAC

Checkpnt
Stamp: 1
Proof: ☑

Msg: /bar
Stamp: 1
Data: ✉HMAC

Checkpnt
Stamp: 1
Proof: ☑

HMAC

Checkpnt
Stamp: 2
Proof: ☑

Msg: /bar
Stamp: 2
Data: ✉

HMAC

Checkpnt
Stamp: 2
Proof: ☑

Message Data
Checkpnts ☑

Message Data
Serialization ✉HMAC

Name,Date,
Device...

Topics

Topics Schema●The nonce and digest for each topic are
retained to verify even IDL info & metadata●Here we’ll choose to hash the topic namemetadata separate from the IDL info

●This allows for message data to remain
verifiable even when want to remap topics●As a superset of the default SQLite schema,bags from the BBR plugin remain compliant

22BBRidnametypeformat

nonce

digest

1/foo

gps

rtps

bitsA

bitsA0

2/bar

imu

rtps

bitsB

bitsB0

3/baz

lidar

rtps

bitsC

bitsC0Messages

Messages Schema
●

●

23

Each message is checkpointed by thetime of arrival and data payload received
Here we’ll choose not to hash the topic ID,
given message is bound to the topic digest

BBR

idtopic

timedata

digest

1

id 1

int64

bits

bitsA1

2

id 2

int64

bits

bitsB1

3

id 1

int64

bits

bitsA2●This allows for message data to remain
verifiable even when want to splice bags●

Checkpoints link to previous message of thesame topic, not necessarily previous insert

Smart Contract●

Checkpoints ensure immutability, but notauthenticity and non-repudiation by itself●

Smart Contracts (SC) encapsulate access
control logic for state in permissioned DLTs●

Digital Asset Modeling Language (DAML) is
used to formalize contract specification●Record/Checkpoint data structures define
the base abstractions used in SC modeling24

16 data Record = Record with -- data type struct17
r_name: Text-- "/sensors/exteroceptive/gps"
18
r_type: Text-- "gps"19
r_format: Text -- "rtps"20
r_nonce: Text -- "<bits_A>"21
r_digest: Text -- "<bits_A_0>"
22
r_checkpoints: [Checkpoint] -- monotonic list

42 data Checkpoint = Checkpoint with -- data type struct43
c_proof: Text -- "<bits_A_1>"
44c_stamp: Int -- 1

Smart Contract●An EDR SC is formed from parties involved
voluntarily entering as obligated signatories●External parties may also provisioned
observational access to the SC state●Control for creating new records, to retain
checkpoints, is delegated to the reporter25

1 template Edr -- Smart Contract for EDRs
2
with3
auditors: [Party] -- Regulatory Agencies
4
custodian: Party -- Robot/Vendor Identity
5
owner: Party-- User/Operator Identity
6
reporter: Party-- Logger/TEE Identity
7
where
8
signatory custodian, owner, reporter -- obligated9observer auditors -- non-obligated parties10ensure unique (custodian :: owner :: reporter)
11
controller reporter can -- create many Records
12
non consuming Edr_Record : ContractEd Edr Record
13with record: Record
14
do create Record with edr = this; record

Smart Contract●

An Record SC is formed from a reference tothe EDR SC and initial record struct object●

Only the Reporter is permitted the choice toappend checkpoints into the ledure state●

Valid checkpoints are appended by asserting
stamps remain monotonically increasing●

Both Reporter and Owner are permitted thechoice to permanently finalize the record26

23 template Edr Record -- Smart Contract for Records in EDR
24 with25
edr: Edr-- Reference EDR of origin
26
record: Record -- Initial Record state
27 where28
signatory edr.owner, edr.reporter
29
observer edr.auditors -- custodian can be excluded
30
choice EdrRecord_Append : ContractEd Edr Record
31with checkpoints: [Checkpoint] -- [] for batching
32
controller edr.reporter -- Only Reporter appends
33
do let -- Update Record with added checkpoints
34
is_valid = check Monotonic record checkpoints
35_record = append Checkpoints record checkpoints
36assert (is_valid == True) -- Error on invalid
37
create Record with edr; record = _record
38
choice EdrRecord_Finalize : () -- Archives Contract
39
controller edr.owner, edr.reporter40
do return () -- Finalized Record is un-appendable

Legend:

Smart Contract●Pending
Custodian,Owner, Reporter

An EDR SC is preliminarily proposed via pending contract
used to collect the necessary multi-party signatories.

●The pending SC is consumed to create the agreed EDR SC●The Reporter may create multiple referencing records andappend checkpoints, that itself or the Owner may finalize

UpdateConsuming
Non-consuming
Create Contract
Reference

EDR
Auditors,
Custodian,Owner, Reporter

Observers,
Signatories

ActiveArchived

RecordAuditors,Owner, Reporter

RecordAuditors,Owner, Reporter27

Results●

Drop Rate & Load performance comparisonof BBR storage/bridge plugins with regard to
ROSBag2's default SQLite plugin.

●Benchmarked via ROS2 Crystal, 2.6GHz
Intel i7-6700HQ, with RTI Connext RMW on
loopback interface.

28

Messages

Conclusion●Engineering trade offs always exist○○●However trade offs can be balanced○○●

Security vs. Performance
Immutability vs. Drop-Rate

Adjusting QoS for sensitive topics
Sparsity via Striding checkpoint

BBRidtopic...

digest

1

id 1

...

bitsA1

2

id 1

...

bitsA2

3

id 1

...

bitsA3

2

id 1

...

bitsA4

Promising uses of DLTs in Cryptobotics○○

EDR applications leveraging distributed consensus
When Byzantine Fault Tolerance is advantageous✓29

Benchmark with consensus○○●

Explore alternative DLT pardimes, e.g:○○●

Profile validator overhead
Characterize scale limitations

Directed Acyclic Graphs vs Blockchains
E.g. IOTA’s Tangle

Record at the middleware level (DDS)○○

Capture all traffic like services/actions
E.g. Parameter updates, planner feedbackDDS
30Swarm 📡
Network●LedgerState 💾Robot
📶 #nFuture WorkRobot📶 #2

Validator
Sawtooth 🔒✓

RMW

RCL

Acknowledgements

Advances in Autonomous,
Distributed and Pervasive systems
31

LinksCurrent Slides: roscon.ros.org/2019/presentations/
ROSCon2019_Black_Block_Recorder.pdf

32

Questions?
●
●
●
●
●
●
●
●
●
●
●
33
●

A113: Full Autopilot Override
BBR: Black Block Recorder
BFT: Byzantine Fault Tolerance
CPS: Cyber-Physical System
DAG: Directed Acyclic Graph
DFI: Digital Forensic Investigation
DLT: Distributed Ledger Technology
DSA: Digital Signature Algorithm
EDR: Event Data Recorder
MAC: Message Authentication Code
ROS: Robot Operating System
SROS: Secure ROS

T DAG
L
D
BFT
SROS

E

BB
R
DR

DFI
DSA
C
A
M

CPS
WUT?

WUT?

References

l.
anru
joeht
Read at easy!
It’s thR. White, G. Caiazza, A. Cortesi, Y. I. Cho and
H. I. Christensen, "Black Block Recorder:
Immutable Black Box Logging for Robots via
Blockchain," in IEEE Robotics and Automation
Letters, vol. 4, no. 4, pp. 3812-3819, Oct. 2019.
doi: 10.1109/LRA.2019.2928780“WALL-E”, Pixar Animation Studios, Walt DisneyStudios Motion Pictures, (film) Jun. 2008.
M. Luthi, A. Sparrow, et al. “WALL-E”, in BOOM!
Studios, (comic) Nov. 2009 - Jun. 2010.
More about:Ruffin: about.me/ruffin
34
Gianluca: about.me/caiazza

Oh.
..

Oh.
..