Configuring EVSE for TLS

[ColinCGC]

Using EVSE v02_01_00, SPI interface. Manual rev 2.17.

I am attempting to configure the wb to accept a TLS connection. I saw in another post one needs to first upload certificates as per the process shown in section 21.8.12, which I am following, but I am running into whitebeet issues and need some guidance.

• I have set (and read back) the time.
• I have opened the own certificate store, received index sync status message 0xA0, with handle of 0.
• Adding certificate then fails, returning the rather unhelpful response code 0xFF (internal error), so I am stuck there. No 0xA0 or 0xA1 status event follows.
• I was running V02_00_01, had the same issues, so then updated to v02_01_00

Questions:

1. The example for 0x60 (20.2.6) cert store open is incorrect, path string length is wrong, string is different from the description, and table does not include what I presume is a length parameter before the string. What is the correct message format and what should the cert store string be (or does it not matter)?
2. Why am I getting an internal error response when trying to add a certificate? Most likely there is something else I need to do or enable first, but documentation on this area seems even lighter than usual. (this is the main issue right now).
3. Is there no set of test certificates already stored on the wb, or provided that I can load, in order to develop/test a TLS connection?
4. Once created, is the cert store persistent or is it volatile?

Something else I noticed, if I (the EVCC) request TLS during SDP, I get a response indicating no TLS and a port of 56789

• is this the expected behaviour?

Thank you, Colin

[nststx]

Hi @ColinCGC,

Thanks for submitting your question. I've taken a look at this and I agree that we definitely need to improve documentation about uploading certificates especially regarding certificate paths (they're currently not documented at all with the exception of one). Thus I'm not surprised that you're facing issues while trying to get your WB ready for accepting TLS connections. The upload procedure you're following looks fine so far. However you're likely getting errors due to incorrect certificate paths (see below for correct paths). Regarding your questions:

1. The example is indeed not correct. We will fix that with an upcoming release. Path string should be 00 15 for the given example. The table not including the string length parameter is expected however as the string parameter is almost always preceeded by a length parameter. For details on this please refer to section 10.3.3 of the 2.17 User Manual. The certificate path in the example is just an example path and not the path that you want to use. The CPO certificates should be stored under fs/cert/v2g/own/shared and the MO certificate under fs/cert/v2g/trusted/mo. This is currently not documented, which we'll fix.
2. You're getting the error response code because the WB isn't able to find the path that you've taken from the example in it's filesystem (which is expected as that's only an example path). Given the new paths this issue should be fixed.
3. No we unfortunately don't have a set of test certificates uploaded by default.
4. Certificates are persistent as they're written directly to the WhiteBeet's root filesystem.
5. This is expected behavior. The EVSE checks if it has the necessary certificates available before offering TLS encrypted connections. Since the certificates are missing the WB only offers unencrypted connections. Once certificates are uploaded this should be fixed.

I hope I could clarify your questions. The main thing that's currently keeping you from uploading the certificates is the wrong certificate path. If you upload the certificates to the correct paths instead it should work. If you have any questions left or need further guidance on how to get your WB ready for TLS, please feel free to ask!

Best regards, Niklas Stoffers

[ColinCGC]

Thank you for your comments Niklas, very helpful, I will give it a go.

With the SDP question, it is of course correct that TLS is not offered, but what I meant was is the returned port value intentional - I had assumed the port for non-TLS TCP would be returned, not a placeholder (56789). Not a big deal, just curious.

[nststx]

Hi @ColinCGC,

Thanks for the clarification with the SDP. The TCP port that you've got is actually not a placeholder. The TCP port is being randomly generated (TLS port is always the random TCP port + 1). This is required by the ISO standard. That you've got exactly the port 56789 should just be a coincidence.

Best regards, Niklas Stoffers

[github-actions[bot]]

This issue has been marked as stale because it has been open for 14 days with no activity. Please update this issue or it will be closed in the next 7 days.

[ColinCGC]

Hi, I did manage to load certificates + key, and the WB seemed happy, returning a "Loaded" Certificate Status message status for each.

The EVCC is able to connect to the provided TCP port for TLS, but the WB is then not happy about something in the TLS Client Hello message, returning a "Handshake Failure" TLS Alert. I don't know if this is because of something wrong in the client hello message, or something with missing/wrong with the SECC WB TLS setup.

Wireshark log attached

tls_hsfail.zip

TLSv1.2 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 105 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 101 Version: TLS 1.2 (0x0303) Random: 64e73362eb04e0c3b50117cd92d9a7e14f260dcc0b8c21400165104754eaa5be Session ID Length: 0 Cipher Suites Length: 2 Cipher Suites (1 suite) Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 58 Extension: signature_algorithms (len=4) Type: signature_algorithms (13) Length: 4 Signature Hash Algorithms Length: 2 Signature Hash Algorithms (1 algorithm) Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: ECDSA (3) Extension: ec_point_formats (len=2) Extension: trusted_ca_keys (len=23) Type: trusted_ca_keys (3) Length: 23 Data: 0015017bdc63125d77f0ad7feb700d62574e8e8f1cf436 Extension: supported_groups (len=4) Type: supported_groups (10) Length: 4 Supported Groups List Length: 2 Supported Groups (1 group) Supported Group: secp256r1 (0x0017) Extension: max_fragment_length (len=1) Type: max_fragment_length (1) Length: 1 Maximum Fragment Length: 1024 (2) Extension: truncated_hmac (len=0) Type: truncated_hmac (4) Length: 0 Data: [JA3 Fullstring: 771,49189,13-11-3-10-1-4,23,0] [JA3: c8909f02b880cf370d532cf154db4318]

[nststx]

Hi @ColinCGC,

Thanks for your response. I'm glad that for now you're able to load the certificates onto the Whitebeet. I'll take a look at what's going wrong with the TLS handshake and come back to you once I found something out.

Best regards, Niklas Stoffers

[nststx]

Hi @ColinCGC,

I've taken a look at your Client Handshake. You're trying to connect using the TLS cipher suite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256. However unfortunately we only support ephemeral ECDH. Please try connecting with a different cipher suite such as TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256.

Please let me know if you're able to proceed further with the suggested solution. If you have any more questions, feel free to ask!

Best regards, Niklas Stoffers

[ColinCGC]

Thank you - I have tried that already though (with either and both) and it makes no difference.

My assumption was that it is something with the extensions, either something I'm sending that the WB doesn't like or an extension it expects but isn't seeing (like OCSP), but I'm only guessing...

[nststx]

Hi @ColinCGC,

Okay, that's strange. Could you please capture a Wireshark log trying to connect with cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256? Furthermore the WB should also give some hints on what's going wrong in its UART output. Could you please share the UART as well?

Best regards, Niklas Stoffers

[ColinCGC]

Sure, section of UART output is below - it does look a little odd.

[ 112.612] [NOTICE] V2GSVC: Starting in EVSE mode. [ 112.612] [NOTICE] V2GAPP: Listen was started [ 112.618] [NOTICE] V2GSVC: TCP: Listen on port 55156 for non-TLS [ 112.619] [NOTICE] V2GSVC: TCP: Listen on port 55157 for TLS [ 115.157] [NOTICE] V2GSVC: TCP: Listen on port 55156 for non-TLS [ 115.158] [NOTICE] V2GSVC: TCP: Listen on port 55157 for TLS [ 115.164] [WARN ] V2GSVC: TCP: Tried to start but already started! [ 115.165] [NOTICE] V2GSVC: TCP: Client disconnected or connection closed by server [ 115.165] [WARN ] V2GSVC: TCP: Tried to start but already started! [ 115.166] [WARN ] V2GSVC: TCP: Tried to stop but already stopped! [ 115.172] [NOTICE] V2GSVC: TCP: Listen on port 55156 for non-TLS [ 115.173] [NOTICE] V2GSVC: TCP: Listen on port 55157 for TLS

Wireshark: tls_hsfail_ecdhe.zip

TLSv1.2 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 109 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 105 Version: TLS 1.2 (0x0303) Random: 64e73362ee96acd5e863577679f5d3788e27d88a5f713885570f784fc5d54f9a Session ID Length: 0 Cipher Suites Length: 2 Cipher Suites (1 suite) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 62 Extension: signature_algorithms (len=4) Type: signature_algorithms (13) Length: 4 Signature Hash Algorithms Length: 2 Signature Hash Algorithms (1 algorithm) Extension: ec_point_formats (len=2) Type: ec_point_formats (11) Length: 2 EC point formats Length: 1 Elliptic curves point formats (1) Extension: encrypt_then_mac (len=0) Type: encrypt_then_mac (22) Length: 0 Extension: trusted_ca_keys (len=23) Type: trusted_ca_keys (3) Length: 23 Data: 0015017bdc63125d77f0ad7feb700d62574e8e8f1cf436 Extension: supported_groups (len=4) Type: supported_groups (10) Length: 4 Supported Groups List Length: 2 Supported Groups (1 group) Supported Group: secp256r1 (0x0017) Extension: max_fragment_length (len=1) Type: max_fragment_length (1) Length: 1 Maximum Fragment Length: 1024 (2) Extension: extended_master_secret (len=0) Type: extended_master_secret (23) Length: 0 [JA3 Fullstring: 771,49187,13-11-22-3-10-1-23,23,0] [JA3: f3d934a61109e5bc0de13920087b2973]

[nststx]

Hi @ColinCGC,

I've taken a look at your issue again. The whitebeet will only close the tcp connection with a handshake failure if either the cipher suite or the signature scheme is unsupported or it's not able to load the correct certificates. In this case this has to be an issue with the certificates as we support both the cipher suite and signature scheme that were offered during the client hello message. Could you please recheck the certificates that you've uploaded to the whitebeet? This is a little hard to debug without having access to your concrete setup.

Best regards and thanks for your patience, Niklas Stoffers

[github-actions[bot]]

This issue has been marked as stale because it has been open for 14 days with no activity. Please update this issue or it will be closed in the next 7 days.

[github-actions[bot]]

This issue was closed because it has been inactive for 7 days since being marked as stale. If your issue still persists, feel free to reopen!