[00:00.000 --> 00:16.360]  Welcome to my talk on the transition of the German Calibration Law or Eichhecht towards
[00:16.360 --> 00:20.360]  a common European Calibration Law.
[00:20.360 --> 00:21.520]  Why this talk?
[00:21.520 --> 00:27.000]  Well, we all know in immobility a nice system architecture security in private is just
[00:27.000 --> 00:31.920]  do not exist, but there are at least some good starting points.
[00:31.920 --> 00:35.240]  So I thought, okay, let's fix this.
[00:35.240 --> 00:37.560]  But first a bit on my person.
[00:37.560 --> 00:43.280]  I studied computer science at the Technical University of Ilmenau, then I worked at multiple
[00:43.280 --> 00:48.360]  startups in the area of craft databases, renewable energy and e-health.
[00:48.360 --> 00:54.520]  And finally in 2014 I started my own company because I thought, well, it would be easier
[00:54.520 --> 01:02.360]  to sell good open source and open data solutions where you can sell to both sides of an API.
[01:02.360 --> 01:07.600]  But back to immobility.
[01:07.600 --> 01:10.600]  What is an immobility user story?
[01:10.600 --> 01:17.480]  Obviously, an EV driver wants to find a free, compatible and working charging station,
[01:17.480 --> 01:22.480]  which is already complicated enough.
[01:22.480 --> 01:31.160]  Then he wants to charge often as fast as possible, or at least as fast as it makes sense for him.
[01:31.160 --> 01:37.440]  Finally, he only wants to pay what he really consumed, not too much and especially without
[01:37.440 --> 01:38.440]  any surprises.
[01:38.440 --> 01:45.440]  If he is a digital native, he might also demand a real digital process, which simply means
[01:45.440 --> 01:47.400]  he wants an error.
[01:47.400 --> 01:55.520]  And we as Boston people, we want open source and it should be free of bullshit.
[01:55.520 --> 01:57.400]  What is bullshit?
[01:57.400 --> 02:04.920]  Now we all know it, this is especially this big EV driver authorization bullshit.
[02:04.920 --> 02:09.640]  This is where a couple of methods to authorize people in immobility and all of them have
[02:09.640 --> 02:15.400]  not much to do with security, none of them has to do with privacy.
[02:15.400 --> 02:24.640]  We even have a MAC address-based authorization, which I just call cyberterrorism.
[02:24.640 --> 02:30.160]  And even from a business point of view, those methods just do not provide enough collision-free
[02:30.160 --> 02:35.400]  identifications for everyone trying to charge his electric car.
[02:35.400 --> 02:38.760]  So just bullshit.
[02:38.760 --> 02:42.800]  On the other side, we have the charging station operator story.
[02:42.800 --> 02:45.800]  What does the charging station operator want?
[02:45.800 --> 02:50.080]  He obviously wants to sell energy and make money.
[02:50.080 --> 02:55.080]  At the same time, he does not want to pay too much to his energy supplier.
[02:55.080 --> 03:01.000]  So as you can see, multiple parties have to trust the energy measurements.
[03:01.000 --> 03:08.080]  And in the future, we also need secure mechanisms for law-balancing services.
[03:08.080 --> 03:15.480]  Additionally, we have to remember that charging is a distributed remote sales process.
[03:15.480 --> 03:23.000]  And most charging stations run unsupervised without anyone on site who could help you
[03:23.000 --> 03:26.320]  as an EV driver when there's a problem.
[03:26.320 --> 03:33.280]  So there's a real need for 100% security and safety for all processes.
[03:33.280 --> 03:37.560]  And finally, there's the engineer story.
[03:37.560 --> 03:47.040]  Measuring energy is hard, while we know for now more than 100 years how to measure AC.
[03:47.040 --> 03:50.080]  But measuring DC is still hard.
[03:50.080 --> 03:54.120]  And measuring high-power DC is even harder.
[03:54.120 --> 04:00.680]  For the security engineers, we can solve all your issues with script or curfew.
[04:00.680 --> 04:01.840]  Nice.
[04:01.840 --> 04:06.600]  But now we have a key distribution problem to solve then.
[04:06.600 --> 04:12.240]  Measuring energy is not only hard, it's also a heavily regulated area.
[04:12.240 --> 04:19.520]  There is the measuring instrument directive, or short, MIT, from nearly 20 years ago.
[04:19.520 --> 04:27.840]  It defines all of Europe the minimum requirements for any metering device used for billing process.
[04:27.840 --> 04:33.200]  But such an MIT meter is still a very traditional analog device.
[04:33.400 --> 04:40.320]  Therefore, there are additional specifications and projects of the German PTP defining the
[04:40.320 --> 04:48.800]  minimum requirements how to transmit measurements in a secure and trustworthy way over an entrusted
[04:48.800 --> 04:52.360]  computer network, like the internet.
[04:52.360 --> 04:57.760]  This is all about asymmetric cryptography and public key infrastructure.
[04:57.760 --> 05:01.720]  And again, more than 20 years old.
[05:01.720 --> 05:09.120]  All of this led us to the German Calibration Law or Eichrecht, which was defined from
[05:09.120 --> 05:15.680]  2015 to 2019, when it became unally a law.
[05:15.680 --> 05:23.160]  Since April 2019, all charging stations have to measure correctly and send their results
[05:23.160 --> 05:27.640]  using digital signatures, or at least they should.
[05:27.640 --> 05:33.480]  Often we hear the term smart meter gateways when it comes to modern energy systems.
[05:33.480 --> 05:36.520]  What are those smart meter gateways all about?
[05:36.520 --> 05:42.680]  We remember the foundations of secure transmission of measurement data is over 20 years old and
[05:42.680 --> 05:46.240]  well tested in different PTP projects.
[05:46.240 --> 05:51.560]  After this period, the German PTP and the German Federal Office for Information Security
[05:51.560 --> 05:58.680]  started to define a next generation security architecture, which we call today smart meter
[05:58.680 --> 05:59.680]  gateways.
[05:59.680 --> 06:05.200]  But we have to keep in mind smart meter gateways are in fact nothing more than VPN tunnels
[06:05.200 --> 06:09.560]  with application layer gateways to access remote smart meters.
[06:09.560 --> 06:14.960]  This is okay for what an energy supplier wants to do, but this is simply not the use case
[06:14.960 --> 06:15.960]  of immobility.
[06:16.400 --> 06:22.840]  In immobility, measurements have to travel many hots through different operator networks.
[06:22.840 --> 06:30.480]  So from the point of view of the German PTP, the entire value chain has to be certified,
[06:30.480 --> 06:37.160]  which is the poor horror for every operator, because this would mean every firmware update
[06:37.160 --> 06:43.360]  on every charging station and every software update on the backend system would have to
[06:43.360 --> 06:46.320]  be reviewed and certified by the PTP.
[06:46.320 --> 06:50.800]  Clearly, this would be the end of all innovation in this market.
[06:50.800 --> 06:57.240]  So a much better approach is to use digital signatures, because by using digital signatures
[06:57.240 --> 07:04.760]  we can be sure that measurement cannot be falsified by random errors, internal attackers or management
[07:04.760 --> 07:05.760]  fraud.
[07:05.760 --> 07:09.840]  The same idea is also used within a charging station itself.
[07:09.840 --> 07:16.480]  As the entire charging station is the management device, everything is regulated again.
[07:16.480 --> 07:24.280]  Even every small firmware update will be regulated, but you can make life much easier with computer
[07:24.280 --> 07:28.520]  scientists best friends and encapsulation and interface.
[07:28.520 --> 07:35.000]  Every regulated function is encapsulated within the so-called measurement capsule, which is
[07:35.000 --> 07:41.880]  more or less just a small energy meter with additional digital signatures and a good real-time
[07:41.880 --> 07:42.880]  clock.
[07:42.880 --> 07:49.080]  All this is located within a small enclosure within the charging station, so it is well
[07:49.080 --> 07:52.720]  separated from everything else within the charging station.
[07:52.720 --> 07:58.320]  The strange part of the current regulation is that there must be a display and the EV
[07:58.320 --> 08:05.480]  driver must be able to look onto the meter, read measurements and the public key, maybe
[08:05.480 --> 08:13.080]  take a photo with his smartphone, because nobody can remember public keys.
[08:13.080 --> 08:18.960]  Unfortunately, this might only be a greater deal when you sit all day in the ivory tower
[08:18.960 --> 08:20.360]  of the MID.
[08:20.360 --> 08:26.200]  In daily life of an operator, it looks more often like this.
[08:26.200 --> 08:34.120]  Good luck finding the public key, reading, metering data or verifying your invoice.
[08:34.120 --> 08:42.480]  Fun fact, this requirement exists just because of a single stupid sentence within MIT regulation
[08:42.480 --> 08:50.840]  and even the German PDB complained about it 18 years ago and no one fixed it since then.
[08:50.840 --> 08:58.480]  So to conclude, the PDB Gunstigelussel, how we call it in German, is about having a charging
[08:58.480 --> 09:05.920]  station with a secure smart meter here on the left, which sends at least a charging start
[09:05.920 --> 09:13.160]  and a charging stop measurement, including some sort of EV driver or session identification
[09:13.160 --> 09:17.720]  to the charging station of a radar backend here in the middle.
[09:17.720 --> 09:23.480]  In the operator backend, we combine both into a so-called charge detail record and send
[09:23.480 --> 09:27.920]  it towards the immobility provider here on the right.
[09:27.920 --> 09:33.360]  He puts all information into an invoice and sends it to you, the EV driver.
[09:33.360 --> 09:40.880]  The new or the PDB can take a so-called transparency software to verify the digital signatures
[09:40.880 --> 09:44.480]  of the measurements and everybody might be happy.
[09:44.480 --> 09:51.080]  Well, in theory, this is true, by and the way, when you ask yourself why don't we send
[09:51.080 --> 09:59.840]  it directly to the electric vehicle, even the ISO 1511820 standard from 2022, so last
[09:59.840 --> 10:05.200]  year, does not support the use case of the German calibration law.
[10:05.200 --> 10:11.040]  Also, the fundamental data structures and the public keys do not fit together.
[10:11.040 --> 10:16.520]  With relations immobility, you fucked it up again, but back to the good parts.
[10:16.520 --> 10:20.320]  What is this transparency software all about?
[10:20.320 --> 10:27.760]  Well, the transparency software is some sort of virtual display on the energy meter, which
[10:27.760 --> 10:31.960]  can validate the digital signatures of all measurements.
[10:31.960 --> 10:37.480]  Therefore, it's also a legal part of the charging station certification process and
[10:37.480 --> 10:41.120]  it also suffers from all kind of regulations.
[10:41.120 --> 10:47.920]  A common way to satisfy one of these regulations is to put the transparency software onto a
[10:47.920 --> 10:50.360]  Linux live ISO image.
[10:50.360 --> 10:56.280]  This is perhaps an unexpected but a quite cool application of open source software.
[10:56.280 --> 11:02.880]  Because we disliked all this politics and immobility, we created our own transparency
[11:02.880 --> 11:03.880]  software.
[11:04.240 --> 11:09.920]  It was the first really open source transparency software and still is the only real open source
[11:09.920 --> 11:13.240]  project in the area of the calibration law.
[11:13.240 --> 11:19.240]  It understands line measurements from different vendors and it's based on the Electron framework.
[11:19.240 --> 11:23.400]  So it is based on TypeScript, SCSS and HTML.
[11:23.400 --> 11:26.480]  The source code is available on GitHub.
[11:26.480 --> 11:32.320]  Feel free to become a sponsor.
[11:32.320 --> 11:37.400]  Let's first look at the typical charge transparency record.
[11:37.400 --> 11:40.720]  In this case, this is just a simple JSON file.
[11:40.720 --> 11:47.600]  It is all the required measurement data, additional metadata and information how to verify the
[11:47.600 --> 11:53.920]  digital signatures, which might be based on some other data format, often a binary data
[11:53.920 --> 11:54.920]  format.
[11:54.920 --> 12:00.800]  How this is done in detail, we will see in a moment.
[12:00.800 --> 12:15.360]  When we now load a typical charge detail record, we will see here one or more charging
[12:15.360 --> 12:17.760]  sessions on the left.
[12:17.760 --> 12:25.840]  Already here, we can see whether the status of the digital signature is okay or not.
[12:25.840 --> 12:29.880]  When we click on one, we can see details on the right.
[12:29.880 --> 12:34.400]  Here we can see whether the validation of individual measurement values is correct or
[12:34.400 --> 12:41.200]  not and whether all measurement values together are a valid charging session.
[12:41.200 --> 12:47.480]  This is important because caused by errors within the charging station or the back ends,
[12:47.480 --> 12:52.440]  one of the signed meter values might be missing or it's a duplicate or some other logical
[12:52.440 --> 13:01.520]  problem occurred when we now click on the details of one of the measurement values.
[13:01.520 --> 13:10.600]  We see how this measurement value was constructed and how it is validated, how the string for
[13:10.600 --> 13:24.240]  plain data must be constructed, how it is hashed, what the public key is and what the
[13:24.240 --> 13:28.440]  expected digital signature is about.
[13:28.440 --> 13:36.840]  When it's correct, you will see a nice, abalytic signature.
[13:36.840 --> 13:37.840]  That's it.
[13:37.840 --> 13:43.600]  At the end, nothing really complicated.
[13:43.600 --> 13:49.720]  As an e-V-Driver, which transparency software I have to use, because there might be different
[13:49.720 --> 13:56.640]  transparency software for different vendors of charging stations, which version of software
[13:56.640 --> 13:59.520]  I have to use.
[13:59.520 --> 14:06.840]  We have seen getting the public key is also not that easy, will I really understand the
[14:06.840 --> 14:11.400]  user interface and user experience of this software?
[14:11.400 --> 14:12.400]  What about billing?
[14:12.400 --> 14:19.560]  e-V-Drivers want to verify invoices, not really meeting values.
[14:19.560 --> 14:24.840]  So where do I get authentic and timestamp charging tariff information?
[14:24.840 --> 14:31.440]  Again, in theory, in Germany, we have a law for this and in other lands, we have even
[14:31.440 --> 14:38.800]  law that you have the right to get a real-time tariff information before, during and after
[14:38.800 --> 14:39.800]  charging.
[14:39.800 --> 14:44.080]  So, again, we are missing in an overall architecture.
[14:44.080 --> 14:51.080]  But don't get me wrong, eichrecht as a digital process is very reasonable, but it fails in
[14:51.080 --> 14:56.960]  daily operations and the immobility really nothing fits together.
[14:56.960 --> 15:04.440]  Security requirements are often not understood and security goals cannot be realized.
[15:04.440 --> 15:09.160]  And surprise, we even have some new regulations.
[15:09.160 --> 15:17.760]  Since the end of last year, we have NS2 cybersecurity regulation and a regulation for the silence
[15:17.760 --> 15:19.840]  of critical entities.
[15:19.840 --> 15:26.080]  The entire charging station infrastructure is now part of the sectors of high-criticality.
[15:26.080 --> 15:32.440]  At the moment, there's not a problem, but become the next big problem of immobility.
[15:32.440 --> 15:40.000]  And do you really want to quit law management with untrustworthy metering data?
[15:40.000 --> 15:44.000]  So yes, well, we have a problem.
[15:44.000 --> 15:49.200]  Again, let's reboot the immobility protocol landscape.
[15:49.200 --> 15:54.900]  This time, we hopefully think twice about fundamental protocol requirements and our
[15:54.900 --> 15:57.500]  design goals.
[15:57.500 --> 16:04.380]  It must not again be just a loosely coupled union of very different protocol kingdoms,
[16:04.380 --> 16:11.900]  which do not play together nicely, just because no one wants to talk to the kingdom next to
[16:11.900 --> 16:13.100]  him.
[16:13.100 --> 16:19.380]  It must also not again ignore 40 years of computer science, security and privacy research
[16:19.380 --> 16:26.860]  and reinvent every bad idea of what had already been deprecated somewhere else 20 years ago.
[16:26.860 --> 16:32.620]  It must become a true Internet of Energy, which means we have an open source first development
[16:32.620 --> 16:41.060]  and government approach without any walled gardens, without any excuses.
[16:41.060 --> 16:46.980]  It must be a rock solid, secure, privacy-aware and extensible architecture with a minimal
[16:46.980 --> 16:53.900]  government overhead, just to coordinate the development of higher level business applications.
[16:53.900 --> 16:59.380]  No one should again wait 10 or more years until basic protocol design flaws inhibiting
[16:59.380 --> 17:04.700]  his business innovation are fixed.
[17:04.700 --> 17:11.180]  We really need a common language for all entities, common semantics and a common understanding
[17:11.180 --> 17:18.460]  of errors and error mitigation strategies within distributed real-time systems.
[17:18.460 --> 17:25.140]  It just does not make any sense that we for example still have important immobility protocols
[17:25.140 --> 17:31.740]  which do not have any concept for charging stations and everybody has to work around
[17:31.740 --> 17:34.380]  this limitation.
[17:34.380 --> 17:40.020]  The Charger transparency software again will go ahead and in the next version we will heavily
[17:40.020 --> 17:43.100]  extend the ways we make use of good cryptography.
[17:43.100 --> 17:49.340]  There will no longer be just cryptographic keys to sign energy meter measurements, but
[17:49.340 --> 17:54.620]  also keys for charging station operators to sign business to business and business customer
[17:54.620 --> 17:58.540]  turrets and invoices.
[17:58.540 --> 18:04.900]  Operators will also sign every update of static location and real-time usage data.
[18:04.900 --> 18:11.260]  This will close this missing link between the EV driver use case of validating a B2C
[18:11.260 --> 18:17.140]  invoice and the currently limited reality of just providing signed energy meter measurement
[18:17.140 --> 18:22.780]  values without any terrific information.
[18:22.780 --> 18:33.500]  Also immobility providers can sign their B2C invoices using their cryptographic keys.
[18:33.500 --> 18:40.140]  Some keys will allow the immobility provider to sign anonymous EV driver identities.
[18:40.140 --> 18:44.860]  This is a newer concept which should replace the current EV driver authorization bullshit
[18:44.860 --> 18:52.780]  in the market and solve all related security and privacy issues.
[18:52.780 --> 18:59.700]  Those anonymous identities are just a guarantee for a charge point operator that an immobility
[18:59.700 --> 19:03.100]  provider will pay the debt.
[19:03.100 --> 19:08.580]  It will no longer leak personal data and as all certificates have a very short lifetime
[19:08.580 --> 19:16.060]  over just few days or even hours, correlation attacks will also be something of the past.
[19:16.060 --> 19:23.340]  Finally all grid load management operations also need cryptographic security and transparency.
[19:23.340 --> 19:29.740]  When an EV driver receives less energy or less kilowatt hours as advertised, he should
[19:29.740 --> 19:35.500]  receive a trustworthy explanation why this happened.
[19:35.500 --> 19:39.860]  Chargy will also become support by a system project.
[19:39.860 --> 19:45.340]  The Chargy Software as a Service API will solve all issues around providing trustworthy
[19:45.340 --> 19:52.340]  charging station location, real-time and security related data, which we see today not only
[19:52.340 --> 19:58.460]  in market-driven solutions but also in governmental immobility databases.
[19:58.460 --> 20:01.020]  This idea is also nothing new.
[20:01.020 --> 20:06.620]  In fact, it's just a copycat of e-regulations we can find in the e-health sector.
[20:06.620 --> 20:12.940]  The EU Medical Device Regulation and the Eudermid Database define both in great detail how
[20:12.940 --> 20:18.660]  vendors have to provide all data around the company and their device models, their device
[20:18.660 --> 20:26.780]  certifications and their sold devices publicly and as open data.
[20:26.780 --> 20:31.900]  Also the operators of those devices have to provide data about their companies, about
[20:31.900 --> 20:40.660]  how they manage those devices and about the most interesting data set device self-tests.
[20:40.660 --> 20:46.980]  Because there is just nothing more trustworthy than a daily authentic digital-signed self-test
[20:46.980 --> 20:49.460]  from each individual device.
[20:49.460 --> 20:54.940]  When the e-health sector can provide such data, there is just no excuse for the immobility
[20:54.940 --> 20:59.380]  sector not to do the same.
[20:59.380 --> 21:05.460]  For this we need a protocol suite which goes far beyond the current state-of-the-art Excel
[21:05.460 --> 21:10.700]  and SQL table transport protocols used in immobility.
[21:10.700 --> 21:16.860]  We want protocols which are defined for server-to-server communication, be fully asynchronous, real-time
[21:16.860 --> 21:20.300]  and provide end-to-end security and privacy.
[21:20.300 --> 21:25.620]  We have to remember that currently state-of-the-art real-time data and immobility means real-time
[21:25.620 --> 21:32.660]  data that is at least three to five minutes old and thus often worthless for any real
[21:32.660 --> 21:35.340]  business decisions.
[21:35.340 --> 21:40.420]  This was my very short and fast introduction to the very interesting world of regulations
[21:40.420 --> 21:43.340]  and collaborations in immobility.
[21:43.340 --> 21:49.940]  Why this is important, why we cannot and must not avoid it any longer and why it is
[21:49.940 --> 21:56.020]  really an interesting starting point for fundamental new immobility protocol architecture
[21:56.020 --> 22:00.620]  and real digital processes.
[22:00.620 --> 22:03.780]  So thank you for your audience.
[22:03.780 --> 22:08.300]  Please use the first and chat applications for your questions and suggestions.
[22:08.300 --> 22:12.100]  Use the issue you management on GitHub or send me an email.
[22:12.100 --> 22:16.420]  You can also sponsor our work and the further development of this project on GitHub.