IT security becomes a system

Keeping security cameras secure

A high security system for surveillance cameras that would make it possible to use images as evidence in court. This was the goal of a project conducted at the Stuttgart-based Steinbeis Transfer Center for Mobile Communications and Embedded Systems. The Center carried out a security analysis on cameras for a company in the security technology sector. The project involved cryptographic issues, as well as a variety of network and platform security issues.

The system to be analyzed consisted of a camera with its own computer installed in critical locations. Typically such cameras are found in bank entrances or shopping areas frequented at night by drug dealers. The system also allows an operator at the police station to access camera data via PC and transfer information or administer the data.

The producer suggested using passwords to authenticate the identity of the operator. Logging in to the computer on the camera starts a session that disables root logins. ftp was used to transfer data. And telnet was used to control the camera, which had corresponding servers. Images captured on the camera were also digitally signed with a private key used by the camera. The operator was also responsible for transferring data and managing the target system at the police station. For legal reasons, operators had to be sure – and in a position to prove – that the data captured by the system was from a genuine surveillance camera. The data had to come only from that specific surveillance camera, so it also had to be impossible for third parties to produce audio visual data themselves and smuggle it into the system as a court case based on such falsified data would be untenable.

Each camera operated independently in a public area so it had to be protected from outside influence. The producer made it impossible to login to the device from outside with root privileges. To administer the unit locally it was therefore necessary to plug in a separate local terminal with root authorization, which in turn involved opening the camera. This process is time-consuming and can be worked out by others by looking at damage to screw fittings. It is unlikely that a hacker would be able to access the terminal, but for an administrator this was essential.

To fulfill the legal requirements of “indisputability”, the camera would have to be able to sign image data with a private section of an asymmetrical pair of keys. In front of the actual signature, audio visual data would be hashed. Or in other words it would be given a short, indisputable identification number.

This is where the input of the Steinbeis experts was needed: cryptography. The MD5 algorithm used is no longer considered safe as experts managed to create so-called collisions some time ago that put the authenticity of the signed data at risk. It was therefore recommended that the producer uses a much more secure algorithm called SHA-256, especially for long term security. The signature key length was also extended.

The private key resides on the hard drive of the camera and can only be read by a user defined as “root”. As remote logins are not given root privileges, the application in the camera that adds the signature either has to run as the root itself or use a setUid program to add the signature. This corresponds better to the “Principle of Least Authority” (POLA) rather than letting the whole, much more complex application run with full root privileges. A login via UserID password casts doubt over the quality of passwords and safekeeping, so the producer was also given recommendations about password practices.

So why is the signature key kept on the hard drive? Because it must be possible for the camera to sign data automatically. And only the camera can do this if the key is not compromised. Data can then be safely assigned to individual cameras and it is not possible for operators or third parties to slip in signed data. The non-root concept for telnet and ftp is safeguarded and operators cannot work on signatures via remote logins.

One risk that does remain is that somebody steals the signature key and the entire hard drive. Depending on the length of intervals between checks by the company, this could remain unnoticed for some time. If intruders were able to extract the key, they could then sign data themselves – probably the worst case scenario for the entire system. Given this, it makes sense not to store the key on the hard drive, but instead to keep it in a hardware security module (such as a smartcard reader, plus smartcard) and only allow access with a PIN. Of course this PIN also has to be stored on the hard drive as the camera has to be able to sign material automatically, without operator input. To gain access to the signature key, the intruder would then have to steal the smartcard as well and if one goes missing, this can be logged and trigger an alarm.

It goes without saying that this system is complex but it has to be to ward off the unlikely event of a serious attack. The manufacturer and system operator have to weigh up the risks and decide whether it is worth investing in such a solution. The experts at Steinbeis also took a look at the transfer process between the camera and the operator. To authenticate access, telnet und ftp need a username and password, although both elements are transferred from one system to the other in simple text. Apart from the fact that this can be tapped into by an intruder during transfer, another disadvantage is that there is no authentication at the final point of communication. In other words, operators can not be certain who they are sharing their highly confidential password with. An alternative to telnet and ftp is SSH protocol (secure shell). This method allows reciprocal certified authentication at both ends with a secure channel between the two. As a result, data transfer is safe at either end of the communication channel, as is the content.

A key aspect with security weak points on the Internet is the type of connection between each site. With dedicated lines, the only people with access to cameras are the operators back at base. Alternatively, cameras might be accessible via public lines such as telephone lines or modems. If they are, then depending on the type of connection it may be necessary to install a firewall on the camera.

The Steinbeis Transfer Center provided the client with a comprehensive choice of alternatives. The recommended solution was subsequently introduced leaving in place a much more secure surveillance system. The parameters chosen for the proposed cryptoalgorithms were also designed with mediumterm requirements in mind, and of course to ensure that images could be secured and used as evidence in a court of law.

Share this page