Transcript
This transcript was autogenerated. To make changes, submit a PR.
Hi everyone.
Today we are going to talk about something that's put urgent and often overlooked
how to secure robot networks for the future where quantum computers exist.
The robots we are deploying today, whether in manufacturing, healthcare, defense, or
even logistics, will still be operating five, 10, even 15 years from now.
Meanwhile, quantum computing is evolving rapidly even though large scale
quantum computers aren't here yet, the threat landscape is already shifting.
Robotic systems combine long lived hardware sensitive and operational data.
And real time autonomy, which makes them prime targets for both current, future
current and also our future adversaries.
So my goal today with this topic is to show you how robotics and
how can we architect systems that stay secure for decades.
Let's start with this matter right now.
Quantum computers are expected to break widely used cryptography protocols like
RSA and ECC using Shor's algorithm.
That means the algorithms that secure our robot communications
command channels, and firmware today will be eventually vulnerable.
Even more concerning is the harvest now decrypt later strategy.
Attackers are already collecting encrypted data, telemetry maps, sensor logs,
firmware, blobs so they can decrypt them.
Once the quantum capability becomes available, robots generate long-lived
data, configuration files, mission histories, telemetry archives.
They also receive update and commands that must remain trusted for years.
That long-term value makes a perfect target for quantum motivated adversaries.
Robotic has a unique attack surface because it blends cyber
as well as the physical systems.
A breach in a robot is just about data.
It can cause physical disruptions as well.
Control and telemetry channels can be intercepted and spoofed.
Firmware updates, especially OTA, are a major entry point for attackers.
iRobot communication has high bandwidth and low latency,
making it sensitive to tampering.
Then on top of that, it's not only that, but we also now have cloud integration.
We also have APIs, we have brokers, we have containerized
services that robots depend on.
So there are so many other cloud and broker services plus API and so much
office services that they depend on.
And even with sensor data like lidar or camera streams, they need
authentication because manipulated sensor input can change a robot
behavior and can cause a hacker to easily have control over a robot.
So every layer exposes a different vulnerability, and quantum attacks
will only widen those gaps until we upgrade our cryptography.
The good news is we already have solutions.
NISD has standards.
The first generation of post quantum cryp cryptography algorithm, the
two key ones that we'll talk about is BER and the D lithium Kyber
is a key encapsulation mechanism that provides secure key exchange.
Replacing RSA and ECCD Lithium is a signature algorithm.
That ensures integrity, identity, and trust perfect for things like command
authentication and firmware signing.
These algorithms are lat based, and more importantly, they are ready today.
Open source libraries exist.
Implementations are maturing, and hardware support is almost starting to land.
So after talking about the kit, let's see how we can transition and how we can
bridge the gap with the hybrid models.
So transitioning an entire fleet of robots to new cryptography
doesn't happen overnight.
This is where hybrid cryptography comes in.
A modern runs a hybrid model runs classical algorithms and post
quantum algorithms in parallel.
That means you have R-S-A-E-C-C based systems keep working while PQC adds
a quantum safe layer on top of it.
So if one algorithm is broken, the other still protects the system.
Now hybrid, TTLS or SSH is the first step.
It enables you to gradually upgrade robot communications without even breaking the
compatibility with legacy components.
So it's our, it's the most practical way out there to start your migration.
Today, when we design a quantum safe robot network, we need to
think about entire lifecycle.
From the robot to the cloud to all the systems it's tied to.
At the robot layer, we use lightweight crypto for local
verification and integrity checks.
Since robot have limited compute and power budgets, edge gateways become critical.
They can handle heavier PQC operations, which offloads the cryptographic burden
from the robot while translating the.
Secure protocols and in the cloud, all APIs, mod channels
and remote debugging interfaces should use PQC enabled TLS or SSH.
Finally firmware and OT updates must be signed with a quantum safe
signatures like de lithium that ensures a robot trusts the update 15
years from now just as it does today.
In robotics, zero Trust is no longer optional.
These system operate independently and are often untrusted environments.
Zero trust means we verify every device, every action, every packet continuously.
Robots should prove their identity to maintain the least privilege, a
access, and provide behavioral telemetry so system can detect anomalies.
This identity layer becomes much stronger with PQC.
Quantum safe signatures ensure that identity and trust can be
forged even by future adversaries.
Zero Trust gives us resilience today, and PQC ensures that
it lasts into the quantum era.
Now let's talk about a little bit how we can put into practice.
So if we have to operationalize this, if we have to put a plan
to this, how will we do this?
First of all, step one is cryptographic inventory.
Map every encryption and signing mechanism across your robot ecosystem,
devices, gateways, and cloud pipelines.
Next, how do we prioritize the risk across?
So the most critical areas are firmware command channels, and the OTA.
Then pilot hybrid TLS.
Let's start small.
From there, perhaps a gateway to the cloud, which is connecting
your robot to the cloud.
Observe the handshake, performance of that latency, and even compatibility.
Ensure your hardware modules, HSM and tpms, secure enclaves and are
capable of supporting the PQC.
Finally document the governance and the incident response.
Quantum safe security isn't only algorithms, it's also an
organizational process towards security.
As with any cryptographic transition, there are pitfalls too.
Algorithm substitution is a real issue.
A vehicle algorithm unless you enforce a stricter PQC policy.
Legacy systems often can't suppose support PQC natively.
So rather than replacing them immediately, you can wrap or
sandbox them in secure gateways.
Vendor dependency is another challenge, so not all the vendors
you would use are PQC ready.
But making the decisions on the spot is also difficult because
an organization from a business standpoint is already engaged with
a vendor for such a big inventory.
So try to choose from those modular crypto APIs and clear roadmaps.
And finally, independent testing is also essential.
Cryptography is hard to implement correctly.
But third party validations.
And then having professional services helps catch subtle but critical flaws.
The transition to quantum safe robotics should start now.
First inventory in your cryptography.
Second pilot PQC in control environment.
Third, build the policies and governance.
So transition is consistent and scalable.
Robotics is becoming central to the industry, healthcare,
defense, and also society.
Eventually, the best time to secure these systems was yesterday.
The next best time is today.
I encourage you to join open source communities advancing PQC and robotic
security, and this is a collective effort and the work we do today will
now define the safety and security of tomorrow's autonomous system.
Thank you everyone.