[Feature Request] WAP2-Enterprise EAP-TLS support

[mjmeans]

To be useful as a basis for a security camera, the connection itself should be able to be secure.

[s60sc]

WPA2_PSK is secure.

[mjmeans]

Short answer:

If I understand it correctly, is that WPA2-PSK has a weakness when it is used in continuous sessions because it uses plaintext SSIDs as a seed. And all clients use the same seed for all sessions. So, a successful dictionary attack against any device on a WPA2-Personal network penetrates all connections on that network.

It is secure from the client's perspective, such as a web browser, in that the client can be sure it's talking to something on the local network. The client only cares that it's getting data from the camera. The camera doesn't know it's talking to an authenticated client. Yes, the camera's firmware can institute its own logins as well as a second layer, but once the PSK is penetrated an attacker is already past the strongest gatekeeper. Clients such as web browsers typically don't keep the session active continuously.

So, for that use case WPA2-PSK is fine as long as the PSK is complex enough and as long as web browsers are NOT being used to keep a session running continuously that would allow an attacker to capture an analyze the data long enough to reveal the PSK and gain access to the entire network. This is not the case for a camera to an NVR client which keeps the session running continuously. This poses a serious risk of WPA2-PSK penetration which not only reveals that camera's stream, but all active camera's streams, and access to that entire network segment.

EAP does not suffer from this weakness as each session on each device has its own unique paired master key. So, even if the EAP attack succeeds on one session from one camera it would only reveal the data on that single session and not reveal any other data or gain access to the entire network.

Long answers, please see:

• https://ieeexplore.ieee.org/document/10041465
• https://www.researchgate.net/publication/321349926_Test_for_penetration_in_Wi-Fi_network_Attacks_on_WPA2-PSK_and_WPA2-enterprise
• https://www.techtarget.com/searchsecurity/tip/Why-WPA2-PSK-can-be-a-security-risk-even-with-an-uncracked-key

[s60sc]

The PSK security is the length of the password. HTTPS can be used for authentication - it is implemented by the app (see certificates.cpp) but will slow down the streaming. For enterprise level security with the associated infrastructure a commercial product would be more suitable than a hobby app.

[mjmeans]

Commercial products have additional risks due to being closed source. None of them can be found legally liable (including prison time for fraud) when they sell a "security camera" that isn't actually secure and they have data breaches from inside or state actors. Just read some of their TOS agreements to see everything they disclaim on the security front where you also agree to their own telemetry, which carries its own risks. The best a consumer can hope for, if we're lucky, is that they may have a very public bug bounty program to elicit some level of trust.

I briefly considered disabling all the wireless connectivity for the cam and adding an ethernet port. Then using an ethernet to WiFi with WAP2-Enterprise EAP-TLS bridge. There is another github fully open source esp32 project that implements EAP. But then it seemed silly to run two esp32s to accomplish something that might be possible all on the same board.

In your estimation, how much of the esp32's processor is consumed when streaming 4M pixel full color images at 30 fps? Can the esp32 do that and still have enough processor capacity to spare to even handle EAP if it were implemented in the same project?

[s60sc]

Even a ESP32-S3 can only manage 5fps for a 4M (WQXGA) image. TLS uses a lot of memory.

[mjmeans]

Pity. Hopefully Espressif can send you an engineering sample of the P4 to play with. Of course, all ESP SoCs suffer from itself containing closed source ASICs (where that level of security can't be independently verified). But I suppose a true zero-trust to the nth degree is mythically unobtainable.