Pro Focus LLC | 12/15/14 04:18pm
Which spec sheet mentions encryption?
You name it, AXIS, Bosch, Sony to name a few.
On any given camera Data Sheet @ page with Technical Specifications under Network Security. They all specify HTTPS encryption, also as supported protocols.
Some cameras use a native protocol, which may be different than RTSP and ONVIF. When using a manufacturer's naitive protocol, that may then be encrypted when using SSL/HTTPS/TLS.
A few years ago, the main concern was username/password leakage, whereas video stream security is now a newer concern. In addition, some cameras use digest encryption for username/password transfer even with SSL disabled.
What it would take to properly solve it is most likely much more than the solution is worth in the broader market. Having some background with large banks and common network security best practices, I looked into this in depth a few years ago. For the most part, to be *truly* compliant, most manufacturers would have to make custom high-security firmware, with a lot of common features (email, ftp, etc.) stripped out, and other things (endpoint auth, forced HTTPS tunnelling, unqie certs for each device, certification authentication service) added in.
IP cameras are already more secure than non IP cameras for basic snooping. Then you layer that with some networking best practices (switches in locked/secured rooms, VLANs, physical segregation, endpoint encryption, SNMP link up/down trap alerts from switches) and you have something that would be secure against anything other than a very concerted insider, in which case you technically have no REAL solution. You can go one step further and add tamper switches to housings, pressurized conduits, and things like that as well. It's been done.
The honest answer though is that 98% of the market doesn't care about network security to that level of depth. I know of a few companies that won't put ANY IP device on the outside of their building (for fear of network hacking through outside accessible drops), though some of them are slowly making special exceptions.
What (honestly) are you trying to secure/what is your anticipated threat? Are you worried about someone getting access to the video feeds? (live or recorded?) Are you worried about mitm attacks where video feeds are replaced/altered? Something else?
"When using RTSP over HTTPS then everything is encrypted including the video. VMS partners would need to be able to support calling RTSP over HTTPS from the camera as well."
I have seen some cameras over the years that when you do turn on SSL encryption, the CPU takes a huge hit on performance, and the web interface is slowed down, responses to commands are slower, and you lower the number of clients that can connect.
Hopefully newer generations of cameras have more CPU to handle this, or maybe even hardware SSL offloading from the CPU...??
IMO you need to encrypt the business data. That means the video streams too.
I don't think 802.1X is viable as it's too complicated for all but the most well funded network environments. IPSec between clusters of cameras and the VMS is an adequate answer, sometimes.
Remember many vendors don't even allow TCP let alone TLS, claiming cameras are too weak to run TCP (while running H.264, so this is a weak argument...)
By the way, that's TLS, 1.2, with AES GCM and SHA-256, using properly deployed 2048 bit RSA keys...
afaik, there are only 4 non-proprietary ways to deliver video: Rtp, rtp interleaved with rtsp, interleaved tunneled by http and interleaved tunneled via https.
to avoid leaks via pure rtp, rtsp and http should be explicitly turned off.
from onvif perspective, if camera support https, it must support video over https. At the same time, onvif conformancy do not support proved claims of https support - this is the business of new profile a (advanced security), coming next year.
summary: If camera is onvif profile s conformant and support https and it is possible to swith off rtsp and http via web interface - there are chances thay you will have secure stream. But i have no idea about vms that can handle it.
i expect that next autumn, when there will be devices and vms conformant to profiles S and A, you will be on a safe side.