It would be fine if the footage was end-to-end encrypted, meaning you need to transfer the encryption/decryption keys from device (e.g. a phone) to camera, and then manually between all devices that should have access to the decrypted footage.
Camera would only ever send out encrypted footage, and thus it would be insufficient to have access to the cloud account if you want to view the footage - you would need both access to the account (to obtain the encrypted data) and the decryption key (to actually decrypt it). The decryption key must never reach any 3rd party servers and can only be manually transferred between devices that should have access.
There are still possible vulnerabilities, like malicious firmware updates, or the viewer client app updates, but those are very difficult to exploit, and pretty much exist in most “secure” software today (including from companies like Google, Apple, Meta, etc.). They could be mitigated by hardware design (do the encryption in hardware, camera’s software never has access to decrypted footage) and open source viewer clients that the user controls, but I would consider a camera sufficiently secure (for non-sensitive locations) without those.
Encrypted VPN between each side. IPSEC over GRE using 1024-bit AES encryption is more than enough.
Honestly though, if someones cracking IPSEC with any encryption against a random person then that’s already leagues more than any script kiddie is capable of and professional hackers don’t have the motive.
It would be fine if the footage was end-to-end encrypted, meaning you need to transfer the encryption/decryption keys from device (e.g. a phone) to camera, and then manually between all devices that should have access to the decrypted footage.
Camera would only ever send out encrypted footage, and thus it would be insufficient to have access to the cloud account if you want to view the footage - you would need both access to the account (to obtain the encrypted data) and the decryption key (to actually decrypt it). The decryption key must never reach any 3rd party servers and can only be manually transferred between devices that should have access.
There are still possible vulnerabilities, like malicious firmware updates, or the viewer client app updates, but those are very difficult to exploit, and pretty much exist in most “secure” software today (including from companies like Google, Apple, Meta, etc.). They could be mitigated by hardware design (do the encryption in hardware, camera’s software never has access to decrypted footage) and open source viewer clients that the user controls, but I would consider a camera sufficiently secure (for non-sensitive locations) without those.
How would I encrypt an rtsp stream so I can port forward it and then how to I unencrypt that stream for use on a local server?
Encrypted VPN between each side. IPSEC over GRE using 1024-bit AES encryption is more than enough.
Honestly though, if someones cracking IPSEC with any encryption against a random person then that’s already leagues more than any script kiddie is capable of and professional hackers don’t have the motive.
I guess you wouldn’t. Use a different protocol, one that supports the security you need.
“how would I do something that is impossible because I think I’m making a clever point”
use a different protocol