WEBVTT

00:00.000 --> 00:16.000
Let's keep it going, the next speaker for the Syrian practice

00:16.000 --> 00:21.000
death room is a Jim Freeland and is going to talk about CRA by design,

00:21.000 --> 00:26.000
protocol embedded compliance for EV charging infrastructure.

00:26.000 --> 00:28.000
Take it away, sir.

00:28.000 --> 00:31.000
Thank you, I hope you can hear me.

00:31.000 --> 00:39.000
Yes, as you see, we keep in the area of electric mobility,

00:39.000 --> 00:45.000
but we switch a little bit to bribe its battery electric mobility.

00:45.000 --> 00:51.000
As you can see, already 2400 years ago, Mr. Blato tried to charge his E-dunky

00:51.000 --> 00:54.000
and it didn't work.

00:54.000 --> 00:59.000
The problem here is, yeah, EV charging isn't no longer really a nice

00:59.000 --> 01:02.000
internet of broken things, topic.

01:02.000 --> 01:08.000
It's getting like Deutsche Bahn into the area of critical infrastructure,

01:08.000 --> 01:14.000
but the manufacturers are perhaps not yet the area.

01:14.000 --> 01:18.000
This talk is more about architecture, not the legal interpretations,

01:18.000 --> 01:23.000
and it's a little bit because we are practically done guys.

01:23.000 --> 01:27.000
A mixture of cyber resilience acted in this tool because both from

01:27.000 --> 01:31.000
a technique of perspective solve similar problems,

01:31.000 --> 01:34.000
even when the regulation is very different.

01:34.000 --> 01:40.000
So keep this in mind, I'm not a lawyer here.

01:40.000 --> 01:42.000
Come on.

01:42.000 --> 01:45.000
You have noticed the mobility is exploding,

01:45.000 --> 01:49.000
but it's still the same all-ship and forget-muntality,

01:49.000 --> 01:54.000
security, resilience, adaptability, life-saken management,

01:54.000 --> 01:55.000
all the ability.

01:55.000 --> 01:58.000
It's a little bit better in Germany because, you know,

01:58.000 --> 02:01.000
Germans like it in a correct way,

02:01.000 --> 02:06.000
but Germans are also very known for they do not care about the end user.

02:06.000 --> 02:13.000
So this created a lot of technical depth over the last 15 years of

02:13.000 --> 02:19.000
mobility, and how can we start to solve that?

02:19.000 --> 02:26.000
One problem is if you're charging is not a very simple domain,

02:26.000 --> 02:31.000
perhaps the most common use case is when you think you go to a charging station,

02:31.000 --> 02:34.000
instead in front of a charging station, you have to display,

02:34.000 --> 02:38.000
then it's quite simple because you have a broader

02:38.000 --> 02:42.000
element and a user is using it directly.

02:42.000 --> 02:47.000
That's fine, that's more or less also in scope of a cyber-resolence act,

02:47.000 --> 02:50.000
but we're also connecting a car,

02:50.000 --> 02:52.000
perhaps they're sitting in a car and remote control,

02:52.000 --> 02:54.000
the charging station, we are the car.

02:54.000 --> 03:00.000
Then the cyber-resolence act is no longer the only thing we have to respect.

03:00.000 --> 03:05.000
There are other regulations we have to do something about it.

03:05.000 --> 03:10.000
Normal way would be now we open Excel, create a mapping table between

03:10.000 --> 03:13.000
the one regulation and the other regulation,

03:13.000 --> 03:16.000
and just be happy with compliance.

03:16.000 --> 03:19.000
But again, we are not here for compliance,

03:19.000 --> 03:23.000
we are here for architecture and technology.

03:23.000 --> 03:28.000
The next thing is we have a problem, perhaps we have a charging station,

03:28.000 --> 03:31.000
perhaps we have a little controller because of energy,

03:31.000 --> 03:33.000
if it swings and so on.

03:33.000 --> 03:41.000
Then we go through a long, long, long path of software and server systems.

03:41.000 --> 03:44.000
So they are not regulated in a cyber-resolence act,

03:44.000 --> 03:49.000
perhaps some of them will be in the future regulated and then this too.

03:49.000 --> 03:57.000
We have some strange definition in the cyber-resolence act,

03:57.000 --> 04:01.000
and the foreseeable use, and the foreseeable use,

04:01.000 --> 04:05.000
obviously they are included in this path.

04:05.000 --> 04:10.000
At the moment, we do not know how we really have to solve this problem.

04:10.000 --> 04:17.000
We will see in the future if those entities which are soft as a service will

04:17.000 --> 04:22.000
be somehow regulated or if a manufacturer can say something about

04:22.000 --> 04:26.000
the minimum requirements of these entities in the middle.

04:26.000 --> 04:30.000
But at the moment, we do not know.

04:30.000 --> 04:33.000
So very a lot of other nice regulations.

04:33.000 --> 04:38.000
Everybody knows we use everybody cuts for authentication and charging station.

04:38.000 --> 04:41.000
They do not provide any kind of security.

04:41.000 --> 04:45.000
We have other strange things like make-out dresses of the car,

04:45.000 --> 04:48.000
which is even worse than everybody.

04:48.000 --> 04:50.000
We have a German calibration law,

04:50.000 --> 04:51.000
a wonderful regulation.

04:51.000 --> 04:55.000
We have digital signatures on measurement values,

04:55.000 --> 05:00.000
but how the user should use it and how the user even gets them.

05:00.000 --> 05:03.000
That's not part of this regulation.

05:03.000 --> 05:05.000
So it's not working.

05:05.000 --> 05:11.000
If ISO 15118, which is talking a lot about cryptography and so on and so on,

05:11.000 --> 05:15.000
but it's just the first meter, it's just on the charging cable.

05:15.000 --> 05:18.000
And we have a very quick movement in directives.

05:18.000 --> 05:22.000
And it's active since last August and we see the only,

05:22.000 --> 05:25.000
I should not cross this line.

05:25.000 --> 05:30.000
And we see what the manufacturers are really doing

05:30.000 --> 05:33.000
is they do not encrypt security.

05:33.000 --> 05:37.000
They remove features that operate as depend on

05:37.000 --> 05:39.000
because they are going to know,

05:39.000 --> 05:43.000
it's now secure and you know how long I can use this.

05:43.000 --> 05:47.000
But for example, when you want to read your own

05:47.000 --> 05:49.000
diagnostics look files,

05:49.000 --> 05:51.000
you can download it from the device.

05:51.000 --> 05:55.000
It will be encrypted and you can send it to us via email.

05:55.000 --> 05:58.000
We send you the look files back via email.

05:58.000 --> 06:04.000
I do not know if this is really a solution to a security problem,

06:04.000 --> 06:08.000
but this is what happens in the markets today.

06:08.000 --> 06:14.000
So I would say a red also failed.

06:14.000 --> 06:17.000
When spec failed to produce trust,

06:17.000 --> 06:21.000
we know it already is not the blood security compliance

06:21.000 --> 06:22.000
it's not trust.

06:22.000 --> 06:26.000
And the intent to improve security,

06:26.000 --> 06:30.000
but with a solution which lowers security like this,

06:30.000 --> 06:35.000
we send you the diagnostic information we have email

06:35.000 --> 06:42.000
as not perhaps the evidence that we really produce more security.

06:42.000 --> 06:46.000
And as you know, once it's standard or specifications out,

06:46.000 --> 06:48.000
it occupies very fast,

06:48.000 --> 06:52.000
and you have very hard time to improve something.

06:52.000 --> 06:57.000
So we want to use both regulations as design inputs

06:57.000 --> 07:02.000
and go away from security and it's just as best effort

07:02.000 --> 07:07.000
and happens when a manufacturer has a good day

07:07.000 --> 07:15.000
or on a bad day where you don't have much real security.

07:15.000 --> 07:18.000
So from engineers, what does this mean?

07:18.000 --> 07:21.000
We have now to think a little bit what must be enabled

07:21.000 --> 07:26.000
or disabled by default for this charging station.

07:26.000 --> 07:29.000
What's kind of data or information must be observable,

07:29.000 --> 07:32.000
what must be approval in years later?

07:32.000 --> 07:36.000
We talk about charging stations, we have payments,

07:36.000 --> 07:40.000
and we have regulations far away from technology

07:40.000 --> 07:43.000
that say when you have a business process,

07:43.000 --> 07:46.000
you have to provide evidence, stormless evidence,

07:46.000 --> 07:50.000
and prove it even in years later.

07:50.000 --> 07:55.000
Let's not where EV charging is currently.

07:55.000 --> 08:02.000
But also, the uncomfortable tools for regulators is

08:02.000 --> 08:07.000
in immobility, we have not the simple relationship between

08:07.000 --> 08:10.000
the manufacturer and the user.

08:10.000 --> 08:13.000
A user is very often operating more than one device

08:13.000 --> 08:16.000
for more than one manufacturer,

08:16.000 --> 08:21.000
but more than one further version.

08:21.000 --> 08:27.000
So interoperability is a key factor in this area.

08:27.000 --> 08:32.000
We have the same product type,

08:32.000 --> 08:37.000
a risk product type, I mean now charging stations,

08:37.000 --> 08:41.000
from different manufacturers and how do we model it

08:41.000 --> 08:44.000
that they are somehow interoperable.

08:44.000 --> 08:49.000
Because inconsistency of deployments and inconsistency of

08:49.000 --> 08:52.000
compatibility or interoperability,

08:52.000 --> 08:55.000
that also increase our systematic risks,

08:55.000 --> 08:58.000
which are important under this tool for the entire chain,

08:58.000 --> 09:02.000
or even for the product itself,

09:02.000 --> 09:04.000
or for the charging station itself,

09:04.000 --> 09:07.000
when we look at the cyber misalience act.

09:07.000 --> 09:10.000
Luckily since 15 years,

09:10.000 --> 09:14.000
the existing organization is called OpenCharge Alliance,

09:14.000 --> 09:16.000
they produce a protocol.

09:16.000 --> 09:20.000
It's open, it's not like the typical easel standards.

09:20.000 --> 09:23.000
It's really as real like it.

09:23.000 --> 09:29.000
As engineers, it's really as open as ETF error exists,

09:29.000 --> 09:35.000
but it comes from another direction.

09:35.000 --> 09:37.000
It's a management protocol,

09:37.000 --> 09:40.000
how to talk to your charging station.

09:40.000 --> 09:43.000
So the first user of the charging station is more or less

09:43.000 --> 09:45.000
with the operator.

09:45.000 --> 09:49.000
The protocol encodes some key and some two syntax behavior

09:49.000 --> 09:51.000
and error semantics,

09:51.000 --> 09:54.000
and so on, what you imagine,

09:54.000 --> 09:58.000
and defaults matter of course more than options,

09:58.000 --> 10:01.000
but we also see a lot of vendor hex,

10:01.000 --> 10:05.000
because obviously when we try to discuss this,

10:05.000 --> 10:09.000
come to a common ground, this takes always a lot of time,

10:09.000 --> 10:16.000
and vendors or have always some time pressure

10:16.000 --> 10:19.000
to get something on the market.

10:19.000 --> 10:21.000
There's also a logic,

10:21.000 --> 10:25.000
because as I said, OpenCharge Alliance is only in the first step.

10:25.000 --> 10:27.000
So the direct connection to the charging station,

10:27.000 --> 10:29.000
there's a project,

10:29.000 --> 10:33.000
by NG0, it's called EV Quality Infrastructure.

10:33.000 --> 10:35.000
You can go to building,

10:35.000 --> 10:38.000
you can get some stickers for this project.

10:38.000 --> 10:42.000
It's basically extending OCPP

10:42.000 --> 10:44.000
on the other entities,

10:44.000 --> 10:48.000
which you have seen between the charging station and the end user.

10:48.000 --> 10:50.000
So all the middle man,

10:50.000 --> 10:53.000
which are required for EV rooming.

10:53.000 --> 10:56.000
So technical specifications,

10:56.000 --> 10:58.000
break under regulation.

10:58.000 --> 11:00.000
We have the same protocol, but too many rules.

11:00.000 --> 11:03.000
The same protocol, but different acceptable risks.

11:04.000 --> 11:06.000
Why?

11:06.000 --> 11:08.000
Because charging station,

11:08.000 --> 11:11.000
you know charging station can be at home.

11:11.000 --> 11:14.000
At home, you have an operational environment,

11:14.000 --> 11:17.000
which is perhaps not that complex,

11:17.000 --> 11:20.000
but you can also have charging stations in the streets,

11:20.000 --> 11:23.000
and they are regulated under this too,

11:23.000 --> 11:25.000
because they are now critical infrastructure,

11:25.000 --> 11:27.000
high power charging stations.

11:27.000 --> 11:31.000
So you have a wide variety of operational environments,

11:31.000 --> 11:35.000
and therefore very different acceptable risks.

11:35.000 --> 11:38.000
And you have a very different operational environment,

11:38.000 --> 11:42.000
because you can imagine working behind their footsteps.

11:42.000 --> 11:48.000
It's very different to working behind a professional operator network

11:48.000 --> 11:53.000
at a big charging station operator.

11:53.000 --> 11:59.000
Therefore, we came to already a year ago,

11:59.000 --> 12:03.000
we started discussing the cyber-resignance act in the open charging lines.

12:03.000 --> 12:04.000
We came to the conclusion,

12:04.000 --> 12:10.000
we have to split the protocol specification into a technical layer,

12:10.000 --> 12:14.000
which gives us just the information, the bits and bytes,

12:14.000 --> 12:16.000
like, yes, we use TLS.

12:16.000 --> 12:21.000
Yes, we don't use very broken either levels of TLS,

12:21.000 --> 12:26.000
but we do not over specify how we should use TLS, for example.

12:26.000 --> 12:29.000
Because we have seen in 1511H,

12:29.000 --> 12:32.000
this is very awful when you overspecify something,

12:32.000 --> 12:38.000
and then you have an operability problem between the different versions of the same protocol.

12:38.000 --> 12:40.000
And your car is again not charging,

12:40.000 --> 12:44.000
because the charging station expects TLS-1.3,

12:44.000 --> 12:48.000
and you only can talk TLS-1.2.

12:48.000 --> 12:53.000
And it's explicitly forbidden to be downward compatible.

12:54.000 --> 12:57.000
So, we created this separation.

12:57.000 --> 13:00.000
We have a technical layer, we have a secure specification,

13:00.000 --> 13:02.000
and there's a cutine operation skyds,

13:02.000 --> 13:06.000
it's meant specific for every operational environment,

13:06.000 --> 13:08.000
which tells me, okay,

13:08.000 --> 13:10.000
when you are charging station,

13:10.000 --> 13:12.000
you are at home indoors,

13:12.000 --> 13:14.000
let's totally nice,

13:14.000 --> 13:17.000
because you have an easy life.

13:17.000 --> 13:19.000
When you are at home outdoors,

13:19.000 --> 13:22.000
it's already getting a little bit complicated,

13:23.000 --> 13:26.000
because now you have no physical accessibility anymore,

13:26.000 --> 13:30.000
then you have to implement something perhaps differently,

13:30.000 --> 13:33.000
or enable some options in a different way.

13:35.000 --> 13:40.000
This allows us to security and resilience to involve,

13:40.000 --> 13:43.000
because what we really, really want to avoid

13:43.000 --> 13:46.000
is that we soon have a TLS version 1.4,

13:46.000 --> 13:48.000
and again nothing is working,

13:49.000 --> 13:54.000
because the ISO standards defined we have to use TLS-1.3.

13:54.000 --> 13:57.000
That's not really helpful,

13:57.000 --> 14:00.000
and it's also, from my point of view,

14:00.000 --> 14:02.000
for us, kind of, security.

14:03.000 --> 14:06.000
So, we come up from this,

14:06.000 --> 14:09.000
what we see perhaps in this cyber-resignance experience,

14:09.000 --> 14:11.000
very simple,

14:11.000 --> 14:14.000
architecture to a much more complex architecture

14:14.000 --> 14:16.000
with different manufacturers,

14:16.000 --> 14:19.000
they have different products, and we split.

14:19.000 --> 14:21.000
Now, our protocol,

14:21.000 --> 14:24.000
in more or less, free layers.

14:24.000 --> 14:28.000
This idea is also supported by cyber-stand,

14:28.000 --> 14:32.000
but, well, working for cyber-signance,

14:32.000 --> 14:35.000
not as easy as I thought in the first place,

14:35.000 --> 14:39.000
but you will get some nice deliverables.

14:42.000 --> 14:44.000
The next thing is,

14:44.000 --> 14:49.000
as I said, open charter lines already exist in the protocol,

14:49.000 --> 14:51.000
exist in the 15 years,

14:51.000 --> 14:54.000
open charter lines exist in the 11 years.

14:54.000 --> 14:55.000
So, more or less,

14:55.000 --> 14:56.000
everywhere in the market,

14:56.000 --> 15:00.000
we already have this kind of software stewards

15:00.000 --> 15:03.000
or voluntary secure attestation frameworks,

15:03.000 --> 15:06.000
where cyber-insignance actors speaking of.

15:06.000 --> 15:09.000
So, we have some organization in the middle

15:09.000 --> 15:11.000
who already defines,

15:12.000 --> 15:17.000
some parts of our obligations of the cyber-insignance act,

15:17.000 --> 15:20.000
and on the other side of the interface,

15:20.000 --> 15:22.000
provide us some guarantees,

15:22.000 --> 15:24.000
because, open charter-bound protocol,

15:24.000 --> 15:27.000
defines an testing tool.

15:27.000 --> 15:31.000
Wouldn't it be nice if the outcome of a testing tool

15:31.000 --> 15:36.000
would already give us the assumption of conformity,

15:36.000 --> 15:39.000
perhaps, 50% of it.

15:41.000 --> 15:44.000
Because then, also the open charter lines

15:44.000 --> 15:46.000
has a much better standing,

15:46.000 --> 15:49.000
because it's really solving problems for the people,

15:49.000 --> 15:51.000
even for the regulations,

15:51.000 --> 15:54.000
not only for interoperability.

15:54.000 --> 15:56.000
This was the first part,

15:56.000 --> 15:58.000
then,

15:58.000 --> 16:00.000
the next technical issue is,

16:00.000 --> 16:02.000
cyber-signance act,

16:02.000 --> 16:03.000
and this too,

16:03.000 --> 16:06.000
are currently living outside of our protocol stacks.

16:06.000 --> 16:09.000
So, when we consume a service,

16:09.000 --> 16:13.000
it might be produced by a product,

16:13.000 --> 16:18.000
or it's a software service service.

16:18.000 --> 16:22.000
We usually start at the networking layer.

16:22.000 --> 16:23.000
My brief words,

16:23.000 --> 16:26.000
example on the time service of the German PTB,

16:26.000 --> 16:29.000
Deutsche Physikalisch technische Bundesanstalt,

16:29.000 --> 16:32.000
they produce legal time in Germany.

16:32.000 --> 16:37.000
So, charging stations have to consume these legal time,

16:38.000 --> 16:41.000
but in any fact, they just give you four URLs.

16:41.000 --> 16:44.000
Here, please speak NTP to us.

16:44.000 --> 16:47.000
Of course, we can now switch from a normal NTP

16:47.000 --> 16:49.000
to network time secure,

16:49.000 --> 16:51.000
and everything is a bit more secure,

16:51.000 --> 16:55.000
but our resilience is not yet solved.

16:55.000 --> 16:58.000
It's just authentic time.

16:58.000 --> 17:00.000
But nothing more.

17:00.000 --> 17:02.000
Wouldn't it be nice if you have,

17:02.000 --> 17:04.000
okay, thank you.

17:04.000 --> 17:06.000
Wouldn't it be nice if you have some

17:06.000 --> 17:08.000
layer on top of this?

17:08.000 --> 17:10.000
Where we can say, okay,

17:10.000 --> 17:14.000
not only give you information on a strange website

17:14.000 --> 17:16.000
that we have for servers,

17:16.000 --> 17:19.000
and perhaps with the version of the NTS protocol

17:19.000 --> 17:21.000
to speak to us,

17:21.000 --> 17:27.000
could we create some layer 8, I call it,

17:27.000 --> 17:32.000
where we define the governance of this service.

17:32.000 --> 17:33.000
So, that we like,

17:33.000 --> 17:35.000
lateral with this,

17:35.000 --> 17:38.000
theory of forms of in German,

17:38.000 --> 17:41.000
Indian layer.

17:41.000 --> 17:45.000
Describe in an abstract way,

17:45.000 --> 17:47.000
yes, we provide the time service.

17:47.000 --> 17:50.000
We give you all the other metadata,

17:50.000 --> 17:55.000
like the typical DNS records for services,

17:55.000 --> 17:58.000
or the more modern version of services,

17:58.000 --> 18:03.000
data for cryptographic key management,

18:03.000 --> 18:06.000
and service descriptions,

18:06.000 --> 18:08.000
contact information,

18:08.000 --> 18:10.000
all the stuff you know from the cyber design

18:10.000 --> 18:12.000
is actually should provide.

18:12.000 --> 18:14.000
You get this in a JSON,

18:14.000 --> 18:15.000
we get this,

18:15.000 --> 18:17.000
we are well known URL,

18:17.000 --> 18:20.000
this pattern is also not an invention of us.

18:20.000 --> 18:23.000
This well known URL,

18:23.000 --> 18:26.000
defined in a couple of overseas.

18:26.000 --> 18:30.000
And we create a new bus word for all the people who love bus words,

18:30.000 --> 18:33.000
of a digital service passport,

18:33.000 --> 18:37.000
which is directly related to the digital product passport.

18:37.000 --> 18:39.000
We have on the other side,

18:39.000 --> 18:42.000
with the regulations for products.

18:42.000 --> 18:44.000
There we have the same,

18:44.000 --> 18:46.000
we consume this service,

18:46.000 --> 18:47.000
for example,

18:47.000 --> 18:49.000
a traffic station consumes the time service now,

18:49.000 --> 18:53.000
meaning it no longer addresses for service.

18:53.000 --> 18:55.000
It addresses this JSON document,

18:55.000 --> 18:57.000
and gets all the information it needs

18:57.000 --> 18:59.000
from this document.

18:59.000 --> 19:00.000
So we end points,

19:00.000 --> 19:05.000
but also what about the quality of the time,

19:05.000 --> 19:09.000
what are the delay differences between the responses,

19:09.000 --> 19:11.000
so that I can still say,

19:11.000 --> 19:13.000
this is legal time.

19:13.000 --> 19:16.000
Not the one.

19:16.000 --> 19:20.000
So,

19:20.000 --> 19:23.000
as we have seen,

19:24.000 --> 19:26.000
cyber-resignance exercises,

19:26.000 --> 19:29.000
share, expose some of those,

19:29.000 --> 19:31.000
their information.

19:31.000 --> 19:33.000
They have bit other information,

19:33.000 --> 19:34.000
as you know already,

19:34.000 --> 19:36.000
from cyber-resignance activities,

19:36.000 --> 19:38.000
also vulnerability information,

19:38.000 --> 19:39.000
but also,

19:39.000 --> 19:42.000
especially firmware update information.

19:42.000 --> 19:43.000
And in the end,

19:43.000 --> 19:48.000
this enables a much more efficient error reports,

19:48.000 --> 19:51.000
as all context information is directly available,

19:51.000 --> 19:54.000
but you really know when you have to operate devices,

19:54.000 --> 19:56.000
when something is not working,

19:56.000 --> 19:58.000
you get an email with the word,

19:58.000 --> 20:00.000
it's not working,

20:00.000 --> 20:01.000
but nothing more.

20:01.000 --> 20:04.000
Wouldn't it be nice if the device could add

20:04.000 --> 20:07.000
automatically on this context information?

20:07.000 --> 20:09.000
And then the email,

20:09.000 --> 20:11.000
not via email to catch all,

20:11.000 --> 20:14.000
but to specify it,

20:14.000 --> 20:16.000
URL,

20:16.000 --> 20:20.000
and so we come to the conclusions,

20:20.000 --> 20:25.000
first, open source protocols,

20:25.000 --> 20:29.000
not only open source software projects,

20:29.000 --> 20:31.000
should from all point of view,

20:31.000 --> 20:34.000
become cyber-resignance extorts.

20:34.000 --> 20:38.000
Please split your protocol in a technical base layer

20:38.000 --> 20:40.000
in a security operations guide,

20:40.000 --> 20:44.000
provides governance metadata of all your services,

20:44.000 --> 20:45.000
and products,

20:45.000 --> 20:49.000
we are what I call now platons layer,

20:49.000 --> 20:53.000
and consume the governance metadata

20:53.000 --> 20:58.000
to prove all your ongoing processes within your company,

20:58.000 --> 21:01.000
because support requests are really

21:01.000 --> 21:03.000
a hell.

21:03.000 --> 21:06.000
When you don't have the right context information,

21:06.000 --> 21:09.000
so now platon is happy.

21:09.000 --> 21:11.000
That's it.

21:11.000 --> 21:13.000
Thanks.