Let's keep it going, the next speaker for the Syrian practice
death room is a Jim Freeland and is going to talk about CRA by design,
protocol embedded compliance for EV charging infrastructure.
Take it away, sir.
Thank you, I hope you can hear me.
Yes, as you see, we keep in the area of electric mobility,
but we switch a little bit to bribe its battery electric mobility.
As you can see, already 2400 years ago, Mr. Blato tried to charge his E-dunky
and it didn't work.
The problem here is, yeah, EV charging isn't no longer really a nice
internet of broken things, topic.
It's getting like Deutsche Bahn into the area of critical infrastructure,
but the manufacturers are perhaps not yet the area.
This talk is more about architecture, not the legal interpretations,
and it's a little bit because we are practically done guys.
A mixture of cyber resilience acted in this tool because both from
a technique of perspective solve similar problems,
even when the regulation is very different.
So keep this in mind, I'm not a lawyer here.
Come on.
You have noticed the mobility is exploding,
but it's still the same all-ship and forget-muntality,
security, resilience, adaptability, life-saken management,
all the ability.
It's a little bit better in Germany because, you know,
Germans like it in a correct way,
but Germans are also very known for they do not care about the end user.
So this created a lot of technical depth over the last 15 years of
mobility, and how can we start to solve that?
One problem is if you're charging is not a very simple domain,
perhaps the most common use case is when you think you go to a charging station,
instead in front of a charging station, you have to display,
then it's quite simple because you have a broader
element and a user is using it directly.
That's fine, that's more or less also in scope of a cyber-resolence act,
but we're also connecting a car,
perhaps they're sitting in a car and remote control,
the charging station, we are the car.
Then the cyber-resolence act is no longer the only thing we have to respect.
There are other regulations we have to do something about it.
Normal way would be now we open Excel, create a mapping table between
the one regulation and the other regulation,
and just be happy with compliance.
But again, we are not here for compliance,
we are here for architecture and technology.
The next thing is we have a problem, perhaps we have a charging station,
perhaps we have a little controller because of energy,
if it swings and so on.
Then we go through a long, long, long path of software and server systems.
So they are not regulated in a cyber-resolence act,
perhaps some of them will be in the future regulated and then this too.
We have some strange definition in the cyber-resolence act,
and the foreseeable use, and the foreseeable use,
obviously they are included in this path.
At the moment, we do not know how we really have to solve this problem.
We will see in the future if those entities which are soft as a service will
be somehow regulated or if a manufacturer can say something about
the minimum requirements of these entities in the middle.
But at the moment, we do not know.
So very a lot of other nice regulations.
Everybody knows we use everybody cuts for authentication and charging station.
They do not provide any kind of security.
We have other strange things like make-out dresses of the car,
which is even worse than everybody.
We have a German calibration law,
a wonderful regulation.
We have digital signatures on measurement values,
but how the user should use it and how the user even gets them.
That's not part of this regulation.
So it's not working.
If ISO 15118, which is talking a lot about cryptography and so on and so on,
but it's just the first meter, it's just on the charging cable.
And we have a very quick movement in directives.
And it's active since last August and we see the only,
I should not cross this line.
And we see what the manufacturers are really doing
is they do not encrypt security.
They remove features that operate as depend on
because they are going to know,
it's now secure and you know how long I can use this.
But for example, when you want to read your own
diagnostics look files,
you can download it from the device.
It will be encrypted and you can send it to us via email.
We send you the look files back via email.
I do not know if this is really a solution to a security problem,
but this is what happens in the markets today.
So I would say a red also failed.
When spec failed to produce trust,
we know it already is not the blood security compliance
it's not trust.
And the intent to improve security,
but with a solution which lowers security like this,
we send you the diagnostic information we have email
as not perhaps the evidence that we really produce more security.
And as you know, once it's standard or specifications out,
it occupies very fast,
and you have very hard time to improve something.
So we want to use both regulations as design inputs
and go away from security and it's just as best effort
and happens when a manufacturer has a good day
or on a bad day where you don't have much real security.
So from engineers, what does this mean?
We have now to think a little bit what must be enabled
or disabled by default for this charging station.
What's kind of data or information must be observable,
what must be approval in years later?
We talk about charging stations, we have payments,
and we have regulations far away from technology
that say when you have a business process,
you have to provide evidence, stormless evidence,
and prove it even in years later.
Let's not where EV charging is currently.
But also, the uncomfortable tools for regulators is
in immobility, we have not the simple relationship between
the manufacturer and the user.
A user is very often operating more than one device
for more than one manufacturer,
but more than one further version.
So interoperability is a key factor in this area.
We have the same product type,
a risk product type, I mean now charging stations,
from different manufacturers and how do we model it
that they are somehow interoperable.
Because inconsistency of deployments and inconsistency of
compatibility or interoperability,
that also increase our systematic risks,
which are important under this tool for the entire chain,
or even for the product itself,
or for the charging station itself,
when we look at the cyber misalience act.
Luckily since 15 years,
the existing organization is called OpenCharge Alliance,
they produce a protocol.
It's open, it's not like the typical easel standards.
It's really as real like it.
As engineers, it's really as open as ETF error exists,
but it comes from another direction.
It's a management protocol,
how to talk to your charging station.
So the first user of the charging station is more or less
with the operator.
The protocol encodes some key and some two syntax behavior
and error semantics,
and so on, what you imagine,
and defaults matter of course more than options,
but we also see a lot of vendor hex,
because obviously when we try to discuss this,
come to a common ground, this takes always a lot of time,
and vendors or have always some time pressure
to get something on the market.
There's also a logic,
because as I said, OpenCharge Alliance is only in the first step.
So the direct connection to the charging station,
there's a project,
by NG0, it's called EV Quality Infrastructure.
You can go to building,
you can get some stickers for this project.
It's basically extending OCPP
on the other entities,
which you have seen between the charging station and the end user.
So all the middle man,
which are required for EV rooming.
So technical specifications,
break under regulation.
We have the same protocol, but too many rules.
The same protocol, but different acceptable risks.
Why?
Because charging station,
you know charging station can be at home.
At home, you have an operational environment,
which is perhaps not that complex,
but you can also have charging stations in the streets,
and they are regulated under this too,
because they are now critical infrastructure,
high power charging stations.
So you have a wide variety of operational environments,
and therefore very different acceptable risks.
And you have a very different operational environment,
because you can imagine working behind their footsteps.
It's very different to working behind a professional operator network
at a big charging station operator.
Therefore, we came to already a year ago,
we started discussing the cyber-resignance act in the open charging lines.
We came to the conclusion,
we have to split the protocol specification into a technical layer,
which gives us just the information, the bits and bytes,
like, yes, we use TLS.
Yes, we don't use very broken either levels of TLS,
but we do not over specify how we should use TLS, for example.
Because we have seen in 1511H,
this is very awful when you overspecify something,
and then you have an operability problem between the different versions of the same protocol.
And your car is again not charging,
because the charging station expects TLS-1.3,
and you only can talk TLS-1.2.
And it's explicitly forbidden to be downward compatible.
So, we created this separation.
We have a technical layer, we have a secure specification,
and there's a cutine operation skyds,
it's meant specific for every operational environment,
which tells me, okay,
when you are charging station,
you are at home indoors,
let's totally nice,
because you have an easy life.
When you are at home outdoors,
it's already getting a little bit complicated,
because now you have no physical accessibility anymore,
then you have to implement something perhaps differently,
or enable some options in a different way.
This allows us to security and resilience to involve,
because what we really, really want to avoid
is that we soon have a TLS version 1.4,
and again nothing is working,
because the ISO standards defined we have to use TLS-1.3.
That's not really helpful,
and it's also, from my point of view,
for us, kind of, security.
So, we come up from this,
what we see perhaps in this cyber-resignance experience,
very simple,
architecture to a much more complex architecture
with different manufacturers,
they have different products, and we split.
Now, our protocol,
in more or less, free layers.
This idea is also supported by cyber-stand,
but, well, working for cyber-signance,
not as easy as I thought in the first place,
but you will get some nice deliverables.
The next thing is,
as I said, open charter lines already exist in the protocol,
exist in the 15 years,
open charter lines exist in the 11 years.
So, more or less,
everywhere in the market,
we already have this kind of software stewards
or voluntary secure attestation frameworks,
where cyber-insignance actors speaking of.
So, we have some organization in the middle
who already defines,
some parts of our obligations of the cyber-insignance act,
and on the other side of the interface,
provide us some guarantees,
because, open charter-bound protocol,
defines an testing tool.
Wouldn't it be nice if the outcome of a testing tool
would already give us the assumption of conformity,
perhaps, 50% of it.
Because then, also the open charter lines
has a much better standing,
because it's really solving problems for the people,
even for the regulations,
not only for interoperability.
This was the first part,
then,
the next technical issue is,
cyber-signance act,
and this too,
are currently living outside of our protocol stacks.
So, when we consume a service,
it might be produced by a product,
or it's a software service service.
We usually start at the networking layer.
My brief words,
example on the time service of the German PTB,
Deutsche Physikalisch technische Bundesanstalt,
they produce legal time in Germany.
So, charging stations have to consume these legal time,
but in any fact, they just give you four URLs.
Here, please speak NTP to us.
Of course, we can now switch from a normal NTP
to network time secure,
and everything is a bit more secure,
but our resilience is not yet solved.
It's just authentic time.
But nothing more.
Wouldn't it be nice if you have,
okay, thank you.
Wouldn't it be nice if you have some
layer on top of this?
Where we can say, okay,
not only give you information on a strange website
that we have for servers,
and perhaps with the version of the NTS protocol
to speak to us,
could we create some layer 8, I call it,
where we define the governance of this service.
So, that we like,
lateral with this,
theory of forms of in German,
Indian layer.
Describe in an abstract way,
yes, we provide the time service.
We give you all the other metadata,
like the typical DNS records for services,
or the more modern version of services,
data for cryptographic key management,
and service descriptions,
contact information,
all the stuff you know from the cyber design
is actually should provide.
You get this in a JSON,
we get this,
we are well known URL,
this pattern is also not an invention of us.
This well known URL,
defined in a couple of overseas.
And we create a new bus word for all the people who love bus words,
of a digital service passport,
which is directly related to the digital product passport.
We have on the other side,
with the regulations for products.
There we have the same,
we consume this service,
for example,
a traffic station consumes the time service now,
meaning it no longer addresses for service.
It addresses this JSON document,
and gets all the information it needs
from this document.
So we end points,
but also what about the quality of the time,
what are the delay differences between the responses,
so that I can still say,
this is legal time.
Not the one.
So,
as we have seen,
cyber-resignance exercises,
share, expose some of those,
their information.
They have bit other information,
as you know already,
from cyber-resignance activities,
also vulnerability information,
but also,
especially firmware update information.
And in the end,
this enables a much more efficient error reports,
as all context information is directly available,
but you really know when you have to operate devices,
when something is not working,
you get an email with the word,
it's not working,
but nothing more.
Wouldn't it be nice if the device could add
automatically on this context information?
And then the email,
not via email to catch all,
but to specify it,
URL,
and so we come to the conclusions,
first, open source protocols,
not only open source software projects,
should from all point of view,
become cyber-resignance extorts.
Please split your protocol in a technical base layer
in a security operations guide,
provides governance metadata of all your services,
and products,
we are what I call now platons layer,
and consume the governance metadata
to prove all your ongoing processes within your company,
because support requests are really
a hell.
When you don't have the right context information,
so now platon is happy.
That's it.
Thanks.