Skyviia Corporation will debut the company’s performance-driven SV8870 SoC (“System-on-Chip”) multimedia solution as well as its globally deployed price-driven SV8860 HD multimedia decoder solution at IBC 2012. The SV8870, powered by 40-nm ARM® Cortex A9 1GHZ duo core CPU, as well as set-top-box specific IP’s, enables Skyviia’s consumer electronics manufacturing partners to develop the next generation cost-competitive TV-centric entertainment solutions. Already working with selective worldwide Tier-1 manufacturers, the SoC includes the Discretix® CryptoCell® security platform, on-chip content protection.
Posts Tagged ‘embedded security’
Hardware Assisted DRM
Tuesday, November 16th, 2010Hardware and software working in tandem to create effective content protection for connected devices
There was never any doubt about a mobile device’s ability to display video, however the large screens and powerful processors of the new generation mobile devices (smartphones and tablets) offer the consumer a more compelling viewing experience than ever. Moreover, home entertainment devices (TVs, set-top boxes (STB) and DVRs) are increasingly connected to the Internet, opening up a host of new viewing options for TV viewers, outside of the cable operator’s walled garden.
These trends are disrupting the traditional relationships existing between subscribers and service providers. This so-called disintermediation is being felt in the market, with cable operators offering video services to mobile subscribers and mobile operators offering video-on-demand to TV subscribers. Content owners and studios are also modifying their approach by offering services directly to consumers, circumventing the incumbent service providers.
These changes in the market have created new content service providers who must now “prove” their ability to securely deploy premium content in order to gain the approval of the major studios. Content protection – or Digital Rights Management (DRM) as it is more commonly known – is most effective when deployed in conjunction with hardware-based security elements. Principally, the objective of the hardware assets is to hinder scalable attacks, i.e., attacks that allow distribution in the form of exploit code, allowing the service provider to achieve a level of security similar to STBs.
In particular, the hardware-based embedded security is used to protect key elements in the DRM, as follows:
Permanent key material and other permanent sensitive data, including group private keys, device keys, security management keys, metering data
This type of data can be classified as long-term, sensitive data that must be stored permanently in the device. The solution takes the form of an encrypted, integrity-protected secure storage facility. A hardware-based secure storage mechanism is based on an embedded root key that is unique per each device. In order to obtain the Root Key and access the sensitive data, the attacker must physically probe the main processor chip which often results in its destruction. In addition, any information obtained by the attacker is relevant only for that specific device. Physical probing must be repeated to access the sensitive data of another device. This endeavor is both expensive and impractical, and certainly not scalable.
Title related and short term keys (content keys, session keys)
Mobile devices are open systems that run applications from many sources, some of them untrustworthy. The main processor in a mobile device must be deemed part of the threat model since it may be executing malicious code – malware – and attempting to access the content and session keys during run time. This threat is mitigated by running the security critical code that handles these keys in a secure execution environment – a secure subsystem that is inaccessible to the main processor. This hardware-based subsystem cannot be compromised by software-based attacks.
Compressed content (plaintext content before decoding)
Compressed content is output by the DRM client that runs in a secure execution environment and is sent to a codec for decoding and rendering on the output display and audio devices. As noted above, the main processor is deemed part of the threat model, so the compressed content cannot simply be copied from the secure execution environment to the main memory to the codec. In order to secure this interface, the DRM client must be tightly integrated with the codec. The hardware-based solution is to send the compressed content in an encrypted form to the codec. The codec decrypts and then decodes the content.
Thus the combination of hardware-based security working in tandem with a software client creates a robust and effective content protection solution.
Malware Enters a New Phase – SCADA Systems Under Attack
Monday, September 27th, 2010
SCADA Systems Under Attack
It is well known that back in days of IBM PC and MS-DOS malware was mostly created as a hobby to drive vanity of their creators, as a result it was not unusual to cause dire consequences such as formatting the hard-drive. Currently, malware is mostly created for financial gains, such as selling botnets of infected hosts for spam distribution or collection of credit card numbers, as a result it is specifically created to be as stealthy as possible. Recent events hint that we entering a new phase.
Stuxnet is the first publicly known worm to target industrial control systems, often generically referred to as SCADA systems. Not only did Stuxnet include malicious STL (Statement List) code, an assembly-like programming language, which is used to control industrial control systems, it included the first ever PLC (programmable logic controller) rootkit hiding the STL code. It also included a zero-day vulnerability to spread via USB drives, a Windows rootkit to hide its Windows binary components, and it signed its files with certificates stolen from other unrelated third-party companies. All of these characteristics are noteworthy in their own right, however when they all converge within one threat it is clear that there is a special force at work.
As a side-note: industrial systems were designed to be separate from public networks and, once this assumption turns out to be false, the security failures become inevitable.
Letting some air out the Tire Pressure Monitoring Systems (TPMS)
Sunday, August 22nd, 2010
Ironically when a security system contains flaws, it introduces new security problems.
Tire Pressure Monitoring Systems (TPMS) have been compulsory in new automobiles in the US since 2008. The TPMS is supposed to increase car security by reporting low tire pressure. Shortly after the plan became public, the security implications were obvious.
the people who are designing these systems are putting ”zero thought into security and privacy issues.
Now it’s possible to build intelligent improvised explosive devices (IED) capable of attacking specific targets! Or mines that will only disable vehicles with certain tires, e.g. those usually encountered on humvees, while leaving legitimate, civilian traffic alone.
Of course, the implications were obvious only to “professional paranoids”. Now, once the system becomes widely deployed, its security was evaluated is a recent research paper, excerpts of which are quoted below. And while the IED comment is meant as a joke, highway robbers are well known for making drivers pull over by puncturing their car tire. The vulnerabilities of the TPMS show that they can virtually puncture the tire of a specific car.
This paper presents a privacy and security evaluation of wireless Tire Pressure Monitoring Systems using both laboratory experiments with isolated tire pressure sensor modules and experiments with a complete vehicle system. We show that eavesdropping is easily possible at a distance of roughly 40m from a passing vehicle. Further, reverse-engineering of the underlying protocols revealed static 32 bit identifiers and that messages can be easily triggered remotely, which raises privacy concerns as vehicles can be tracked through these identifiers. Further, current protocols do not employ authentication and vehicle implementations do not perform basic input validation, thereby allowing for remote spoofing of sensor messages. We validated this experimentally by triggering tire pressure warning messages in a moving vehicle from a customized software radio attack platform located in a nearby vehicle.
at the end of only two days of sporadic experiments involving triggering the TPMS warning on and off, we managed to crash the TPMS ECU and completely disabled the service.
We attempted to reset the system by sending good packets restarting the car, driving on the highway for hours, and unplugging the car battery. None of these endeavors were successful. Eventually, a visit to a dealership recovered the system at the cost of replacing the TPMS ECU.
More functionality = less security
Sunday, July 11th, 2010It’s often easier to make a complex system from ready parts. Instead of providing specific functionality, the resulting
device does a lot more than you actually need. In so far as the system manages to do what is needed, nobody should complain about the extra functionality. However the extra functionality usually has severe consequences for the device’s level of security. An interesting example of this was presented at Hack in the Box this year.
A wireless presenter – designed to allow only a couple of functions (next/previous), easily achieved with a mouse and a keyboard – can allow someone to take over your computer while you make a presentation.
