Okay, welcome to my talk. We already heard a lot about the fascinating domain of immobility
from the guys from Everest. While Everest is on the charging station side, this project
is more what happens behind a single charging station. So all this back-end stuff up to the
energy providers, distribution network operators and so on. And why is this important? Because in
the energy domain we have a lot of safety and security regulations coming from the government.
We have somehow to comply with it because in immobility it's not only important that you have
IT security, you also need to provide energy safety because everything is connected via the
grid. And so when too many people behave badly, we will have the next blackout. So nothing changed
since last year, so I skip this because I only have 50 minutes. In the past, the immobility was
quite simple. We had charging stations on one side and a back-end on the other side. And they
more or less had been communicating. In the last couple of years we are HTTP web socket
communication. So this is the client, this is the server, everything is fine. But now, the situation
changed a little bit. We have no longer a single charging station somewhere at the street. We have
normally multiple charging stations at one location. So it's quite useful to have some
middle box which combines the communication. So that you save money when you want to communicate
with the back-end. This is nothing new. There's a lot of vendors implementing it. There are even
specialized vendors for this. It's already in the OCPP standard, but it's not really in greater
detail. It's just mentioned that you could do it. We want to dig deeper into this problem and see
what we need to realize in this. Next thing, when you have this middle box, it's very natural that
you add additional stuff to this. So you not only want to combine the communication channel, you
also have specialized energy meters which are now located at the grid connection point. So
monitoring the grid connection point, the idea behind this is that you can do a local load
management because you have only a limited capacity on your grid connection but want to share it
between the charging stations and somebody must be in charge of how to share this energy. There are
other projects who do the calculation for this, but this is the communication part. And here,
for the first time, if you're a German, people, you know, this fascinating world of smart meter
gateways, which is more or less specialized hardware from the federal industry for security in
Germany, which regulate this area because energy, as I mentioned, is a safety critical infrastructure.
So they try somehow to improve the situation that most vendors don't care that much about security
and safety. The first problem would have, because I said we come from a very simplified view on
this problem, where the connection from the charging station to a back end. So because of
limitations of the OCPP protocol, we at the moment duplicate every connection between this charging
or communication aggregation box and the back end. This is not only perhaps a design flaw,
which nobody cares about, it's also starting to become more and more a security problem,
because the only security we have is HTTPS, so transport layer security and transport
layer security and in this box, here you have another transport layer security, so you have a
split communication channel. So your IT security is no longer given, because this could be a man
in the middle. It's getting even worse, because now we have specialized companies who sit in the
middle between your charging stations or your aggregation box and your back ends or even multiple
back ends and want to do analytics for you, because normally the charging station management
operators or vendors just manage charging stations. They are not that much into analytics.
So very often they even those sit in the middle and then you realize, okay, now the problem is
getting more and more complicated, because people who only are interested in Excel sheets sit in the
middle of your critical infrastructure and maybe they not only analyze what you're sending, possibly
here could be sitting Mr. Putin and send commands back, because you have no chance to stop him.
So the first thing what we want to have and this is also nothing really new, we want to
share this web socket connections. For this we need to adapt a little bit the OCPP protocol.
There's already an internal draft how you could do this, but when you look closer at this
draft, so internal means internal in the open charging alliance, which is the organization
managing the OCPP protocol. You see there perhaps a couple of drawbacks. The first thing what we
obviously need, we need to add some additional looting information, so that we know we are
sending from this box to that box and my idea is or my proposal is we can do a lot of interesting
things if we copy this good old concept of the record route taken, which is also an IP version 4
optional option and so we can implement this much more user friendly. Next thing is in the OCPP
internal draft we have more or less source routing, so the sender includes the path through the
network into the request. This is well known, it's a valid way to do it, but it has also a lot of
limitations because when network is changing very often you have a scalability problems. So it's
much more logical to use a normal routing table in every box. You can use this typically outdoor
learning what you know from other net switches, which also on learn which communication partners
on which port and implement it more easily. Now, but it's getting more and more worse because we are
in a modern world. A charging and stage management system today is no longer a monolithic thing on
a notebook somewhere in the Netherlands. It's a highly complex system of microservices and these
microservices are even from different operators. So we have very very often complex systems where
the asset management, so which charging station is located where and coming from which vendor
is within an SAP database, then you have another database for all this real time energy measurements
and so on and so on and so on. So you realize okay now we have a bit of a problem because we
have a critical infrastructure, but in the back end we have a multitude of loosely coupled systems
without much of security. So the traditional also PP security model is also no longer sufficient here.
For this very simple, it would be nice to have digital signatures. Again, there's an internal
traffic and the open charging alliance, but this had signatures on the transport part of also PP.
So it's limited to also PP, but it would be much more interesting to have it on the other PP
messages itself, because then we can send end to end messages and end to end means in this case,
from the EV to the energy distribution grid operator or to the EMP or to the smartphone
of the driver and so on and so on. We will later see a lot of use cases how to make use of it.
What do you, when you want to have signatures, the next problem is you read. As usual, you
reduce the complex problems onto a key management problem. So you need something like signature
policies to define who, which signature is valid, which signature should I use, which
signature should I verify. When you have this signature is implemented, you can extend it
to user roles because at the moment everything in also PP is more or less one user. You have no
differentiation of this communication partner is only allowed to set energy commands. The other
one can also change communication parameters or whatever. This can be implemented using the
signatures. And last but not least, at the moment, also PP is only using the text frames of
HTTP web sockets. But there are a lot of useful use cases for binary streams, especially when
you look at firmware updates or look for downloads because this is at the moment external HTTP requests.
And this makes your network security more complicated. So when you would integrate it into the
also PP protocol, you could close down your network and only allow also PP communication
and improve the security. So nice, all this little details, but what are the real use cases for this?
So in Germany, we have since the first January of this year, there's a nice new law that your
energy provider can send you messages. We are a highly regulated infrastructure to reduce the
amount of energy you're using because we want to renew a bit of energy and so on and so on and so on.
But it's external additional hardware. Why not use the existing infrastructure for this?
The reason? Because it's not secure and safe enough at the moment. Would it be secure and safe enough
if we could perhaps talk to these guys and say, okay, look, we have now improved our infrastructure
why don't we remove this additional hardware?
The same is in the same law, we have a possibility that an energy provider can get your measurements.
This is again a regulated use case. We would do this with our normal also PP infrastructure
with charging tariffs, charging tariffs coming from immobility providers or someone else.
They should also be assigned secure data which is immutable and then used in OCPP.
Good part is that in the upcoming or in the next version of OCPP, there will be some support for
tariffs, not yet end-to-end signed tariffs, but at least half the way.
There is this interesting use case where you want to pay for your charging but in an anonymous way,
so you don't have an account somewhere, but you pay with your smartphone. In the regulation,
they are talking about QR codes. Wouldn't it be interesting that you use this QR code to get
something like a direct communication channel to this charging station over all this complicated
infrastructure, but it's secure so that you have something like a remote control because nobody
stands even not even for 20 minutes in front of the charging station just to look for tapening.
They want to have it on their phones, but for this you need a secure channel.
The same idea, but for another user group, is the charging station operators on the energy people
also often don't know what's really going on on this charging station because it's very limited
for the consent over the wire at the moment. They use a lot of AI to invent what might be happening
on the charging station, but in reality it would be much nicer if we would have something like
this digital twin idea just send everything what is important somewhere where it can be analyzed,
but again we have no secure infrastructure in the middle because every shitty marketing company
could manipulate our data. Better German calibration law, that is my favorite topic, but we had this
already last year. We have national contact points who want to collect all this data and
statistics about your charging station infrastructure, how good or not good it is.
No security, no privacy at the moment. The same problem as usual.
The really biggest problem is this is on the street. Yes, more or less last slide. This is on
the street. There's also on the street, so no physical access security here. So even when we
have encryption signatures, we cannot be sure if not somebody sending us a lot of crap. Okay,
it's a bit harder to manipulate a lot of charging stations on the street, but if you're put in,
probably you would try it anyway. So how or what can we do to analyze it here if this is
a valid request or a valid information or not? And I try to my best to get it into the OPP standard,
but also at the Open Charging Alliance, we have a normal problem. There are many leaching companies
and not so much real contributing companies. So if you find this use case is interesting,
if you think this is interesting for you, for your company, for whatever, feel free to contribute
to this project, feel free to become a member of the Open Charging Alliance and help us to get it
out on the street.
Thank you so much for your presentation.