The cipher ECDH-ECDSA-AES128-SHA256 not support in openssl 1.1.1.

[longrudev]

**Has somebody test with this cipher successfully？And which version of openssl do you install？

I set ssl_context.set_ciphers("ECDH-ECDSA-AES128-SHA256" ) in secc server side. It shows that:**

INFO 2022-09-06 04:57:50,633 - iso15118.secc.transport.tcp_server (110): TCP server started at address fe80::a00:27ff:fe12:a869%eth1 and port 49735 WARNING 2022-09-06 04:57:50,634 - iso15118.secc.transport.tcp_server (123): Closing TCP server ERROR 2022-09-06 04:57:50,635 - iso15118.shared.utils (51): ('No cipher can be selected.',) Traceback (most recent call last): File "/home/pi/projects/pyv2g/iso15118/shared/utils.py", line 49, in wait_for_tasks task.result() File "/home/pi/projects/pyv2g/iso15118/secc/transport/tcp_server.py", line 39, in start_tls await self.server_factory(tls=True) File "/home/pi/projects/pyv2g/iso15118/secc/transport/tcp_server.py", line 82, in server_factory ssl_context = get_ssl_context(True) File "/home/pi/projects/pyv2g/iso15118/shared/security.py", line 181, in get_ssl_context ssl_context.set_ciphers( ssl.SSLError: ('No cipher can be selected.',)

[JanLochi]

Hi,

I was wondering the same thing. The cipher “ECDH-ECDSA-AES128-SHA256” was completely removed in OpenSSL on Feb 11, 2016 with https://github.com/openssl/openssl/commit/ce0c1f2bb2fd296f10a2847844205df0ed95fb8e

I guess one would have to use OpenSSL prior 1.1.0, which would be a bad idea in general...

[longrudev]

Hi,

I was wondering the same thing. The cipher “ECDH-ECDSA-AES128-SHA256” was completely removed in OpenSSL on Feb 11, 2016 with openssl/openssl@ce0c1f2

I guess one would have to use OpenSSL prior 1.1.0, which would be a bad idea in general...

Thank you for your reply.

[JanLochi]

I would still be interested in what SwitchEV thinks about this issue?

[MarcMueltin]

Hi Jan,

You're absolutely right, the “ECDH-ECDSA-AES128-SHA256” is not usable anymore with a current version of OpenSSL. ISO 15118, in principle, allows the two cipher suites

• ECDH-ECDSA-AES128-SHA256
• ECDHE-ECDSA-AES128-SHA256

The difference being the additional "E" in ECDHE. The ECDH version (without the "E" at the end) should have never been introduced to ISO 15118 in the first place, to be honest. ECDH stands for Elliptic Curve Diffie Hellman and is a key agreement protocol used during the TLS handshake, for example, to a calculate the symmetric session key for encrypting/decrypting all the messages exchanged between EV and charger.

The additional "E" stands for "Ephemeral" and indicates that the private-public key pair generated during that TLS handshake for the ECDH key agreement needs to be created anew for each new TLS session. Without the "E" (just ECDH), a charging station could reuse a key pair to create a symmetric session key. This is not considered good security practice as this does not allow for perfect forward secrecy, meaning: if someone gets hold of a private key, they can decrypt previously encrypted messages.

So, OpenSSL removed that cipher suite because of the lack of perfect forward secrecy. Any EV or charger is advices to implement the ECDHE-ECDSA-AES128-SHA256 cipher.

Let me know if you have any further questions.

[JanLochi]

Hi Marc,

Thanks for taking the time to write this extensive answer.

I do fully agree to your reasoning, and I'm aware of the technical implications of the non-ephemeral cipher.

The issue, is more that a SECC is technically speaking not standard-compliant if it does not support both suites:

[V2G2-602] The SECC shall support all cipher suites defined in Table 7, if TLS is used.

So, your argument being, that we can safely assume, there won't be any EVs in the field which only support the weak cipher?

[MarcMueltin]

So, your argument being, that we can safely assume, there won't be any EVs in the field which only support the weak cipher?

Hah, I wish I could promise you that, but there's no way to know that currently, I'm afraid. I think what's really important is to log the TLS information as detailed as possible to be able to debug properly. Just a few days ago, I was presented with a charger log file that indicated a failed TLS handshake with a Ford Mach-E. Unfortunately, there was no detailed information as to why that handshake failed. Could be a mismatch in cipher suites, or several other reasons (certificates expired, signatures could not be validated, certificate attributes not correct, CPO certificate chain in the wrong order).

Another issue with OpenSSL is also that it doesn't seem to support OCSP stapling yet (or at least multi-stapling? I need to dig deeper into that).

ISO 15118-2 was designed between 2010 and 2014, so not all requirements - especially from a security perspective - necessarily make sense anymore.

The ISO 15118 Joint Working Group has been working on a second edition of ISO 15118-2, to rectify the most critical issues while still staying backwards-compatible to edition 1 of ISO 15118-2. I'll raise this issue with the JWG so we can add this topic into the Edition 2.

[JanLochi]

Agreed. Fully support your argument on logging.

I would think that most OEMs just very recently started implementing TLS capabilities at all. Therefore, I would not expect that there are much legacy implementations around from 2010-2014, which only support the weak cipher.

Yes... OCSP is its own can of worms...