Streaming security scares
Where streaming media is concerned, security issues are less to do with technology and more about intellectual property. True to say that, as with all global, mass-market technologies, there is a constant, lurking threat from hackers, spammers and a criminal element. But, as Napster clearly proved, where such technologies are concerned, IP is far more difficult to secure and IP-spoofing could seriously undermine revenue streams.
‘Security features need to be addressed by content and streaming technology providers, and by the service providers themselves,’ says Warren Talbot from Exent Technologies. The goal is to create proper deterrents to insure the casual user can't gain access to content without paying proper fees.’
Talbot goes on to explain that the situation is similar to a bank's safety deposit system. ‘The box is secured by a key and stored inside a secure vault guarded by a heavy door, and the bank itself is guarded by armed guards. The same concept applies online.’
With streaming solutions, access to content must be protected while stored on the server, as it is being streamed to the user, and finally while the content is stored locally -- cached on whatever device is at the receiving end.
But Talbot also warns that security must not affect content performance, which is a view echoed by many in the industry. The truth of the matter is, however, that it does. Layers of security will slow things down -- like the gates on a toll road -- traffic will slow considerably and in some cases come to a dead stop. For streamed content, this is not ideal.
Security, in any form, will also add to the cost of service provision. It really boils down to how valuable the content is to the end user. Video-on-demand, for example, is of low value to the end user, but high value (because it is a revenue stream) to the provider. In this case, providers need to weigh-up the risk of IP-spoofing against the cost of securing content. For banks streaming financial news and information to the city, streamed content may be of high value to the end recipient but of low value to the content provider (as it is news-based it dates quickly). In this instance, the cost of security could be built into the cost of the service and passed onto the end customer.
Robin Smith of Peapod says that all too often security is an after-thought. ‘Service providers need to think about security at the outset. It is much easier to build it into the system to start with than to retrofit later,’ he says.
Ray Stanton from Unisys lays the blame squarely at the feet of the industry's unwillingness to share control. ‘Security differences essentially result from the fact that there are too many protocols and they are all different. The fact that everybody wants control over 'their' data and it's use, as well as control over the market, have initiated protocol wars,’ he says.
Stanton believes that no-one has thought through the development of streaming protocols properly. Worrying, he says, is the fact that most Streaming Protocols (SP's) are still proprietary, which means that they must be reverse-engineered before universality can be achieved. But the problem with this approach is that the resulting protocols are often poorly designed technically, as well as from a security point of view. Another more crucial worry, Stanton points out, is that most streaming protocols are not designed to work with firewalls ‘because they require an oddball mix of TCP and UDP, they need multicast or dynamic ports and they can't tolerate network address translation.’
Some protocols support application level proxies, and others can be fooled into working with such proxies ‘but,’ says Stanton, ‘if you fool it, will it work for multiple concurrent use? More often than not -- it doesn't. If you choose a proprietary protocol, who's going to provide the proxy? Or, to put it another way, why would you want to invest in a firewall product only to be able to run a third-party plug-in module for your SP, when you're quite happy and secure with your $1,000 appliance firewall?’
Some SP's use the SOCKS protocol, which is a generic approach to letting data through the firewall. Generally, if the option of allowing a huge range of incoming connections is disregarded, the most probable solution is to use the proxy approach to firewalling. Big players, such as RealNetworks, Microsoft and Cisco, haven't ignored the issue, but rather they have capitalised on it, in Stanton's view, through product tie-ins. Microsoft's latest player and server are Microsoft Firewall-friendly, for example.
Standardisation attempts are afoot, however. A number of recent forums have resulted in streaming-media-supporting protocols, such as RSVP, RTSP, PNA but mainly for voice-over-IP. To a degree these are still protocol-dependent and proprietary as they only support set-up through a firewall that is SVP/RTSP/PNA aware.
Firewalling is difficult where streaming media is concerned because many streaming protocols cannot be securely firewalled without either performance or security being significantly undermined. H.R323, for example, which was developed to support video-conferencing and voice, cannot be firewalled except by fooling the application, or by having a proprietary extension that can understand proxies.
Niels Rump from digital Rights consultancy, Rightscom, has this to say: ‘Content providers need to establish a set of appropriate business rules for the content (using a Rights Expression Language). Content is then encoded into a bit stream. Packages are wrapped in secure envelopes, which can only be opened with the right key -- for which the customer has to pay.’
Everyone is in agreement that the same is true for the virtual world as it is for the real world and that is that there is no such thing as 100% security. For those tenacious and foolish enough to try, there are holes in software that can be discovered and exploited.