Posts Tagged ‘security’

Hardware Assisted DRM

Tuesday, November 16th, 2010

Hardware and software working in tandem to create effective content protection for connected devices
Tandem Racer
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.

No Comments

Cryptographic pitfalls

Wednesday, October 27th, 2010

The field of cryptography is full of pitfalls. The same can be said about computer science in general, but in cryptography the pitfalls have a distinct character: you may never learn that you have fallen into one.

Let me give an example. Suppose you want to move N bytes starting at address A to the area starting at address B. Since every problem has a simple, fast and wrong solution, one can think that the problem can be solved by a simple loop that moves every byte number X from the first area to the second, where X goes from 0 below N. Once you try to use your program with overlapping areas, you will know that you have fallen into a pitfall: the copy will not look like a copy at all!

Let me now give a cryptographic example. Suppose you want to encrypt a message and decide to use the CTR mode. If you reuse the nonce (IV) for a different message, you compromise confidentiality of your messages, but you may never learn about this: the messages look as scrambled as they were with different nonces.

The confidentiality failure in this example is easy to show. For messages A and B and keystream X, the ciphertexts are A+X and B+X. If an attacker learns one message, he can calculate X and then the second message.

Not all cryptographic pitfalls are that easy to explain. Moreover, it seems that developers are not eager to fix the security problems unless there is a graphic depiction of the failure.

The padding oracle attack was published in 2002:

In many standards, e.g. SSL/TLS, IPSEC, WTLS, messages are first pre-formatted, then encrypted in CBC mode with a block cipher. Decryption needs to check if the format is valid. Validity of the format is easily leaked from communication protocols in a chosen ciphertext attack since the receiver usually sends an acknowledgment or an error message. This is a side channel.

In this paper we show various ways to perform an efficient side channel attack. We discuss potential applications, extensions to other padding schemes and various ways to fix the problem.

but it turns out that even in 2010 many developers continue to make the same mistakes over and over again:

we show that widely used web development frameworks and web sites are using encryption incorrectly in a way that allows attackers to read and modify data that should be protected. It has been known for years in the cryptography community that encryption is not authentication. If encrypted messages are not authenticated, data integrity cannot be guaranteed which makes systems vulnerable to practical and dangerous chosen-ciphertext attacks, one of them being the padding oracle attack presented by Vaudenay at EuroCrypt 2002

What is the proper way to solve all such cryptography misuses once and for all? One approach is to educate the developers, but the experience shows that this approach is not that effective as one may hope. Another approach is based on the observation that if you cannot educate everyone who will use your tools, it pays to make tools that are hard to misuse.

Consider the CBC mode of encryption. One of its main drawbacks is that the message must be padded to a multiple of the cipher block size. This does not only increase the ciphertext size, but also allows to check the integrity of the padding during decryption. In most cases the size increase is negligible, but the ability to &lquot;check&rquot; integrity gives a false sense of security. This misunderstanding leads to spectacular attacks.

Recently, NIST published an addendum that will probably do more to prevent the CBC misuses, than all the warnings that CBC does not provide authentication:

This addendum to [NIST Special Publication 800-38A] specifies three variants of CBC mode that accept any plaintext input whose bit length is greater than or equal to the block size, whether or not the length is a multiple of the block size. Unlike the padding methods discussed in [SP 800-38A], these variants avoid ciphertext expansion.

The new mode does not only save space, but the fact that there is no authentication becomes obvious: if you change a bit in the ciphertext, then some plaintext becomes gibberish, but the decryption function does not even notice.

No Comments

Letting some air out the Tire Pressure Monitoring Systems (TPMS)

Sunday, August 22nd, 2010

Flat TireIronically 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.

No Comments

More functionality = less security

Sunday, July 11th, 2010

It’s often easier to make a complex system from ready parts. Instead of providing specific functionality, the resultingBusiness conference 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.

No Comments

Side-channel attacks for Software-as-a-Service

Sunday, June 27th, 2010

Side-channel attacks (SCA) are usually associated with high-tech equipment used to monitor power consumption and electro-magnetic emanations of a smart card. Yet a web server thousands mile away can also by attacked using SCAs. As shown in a recent research paper, monitoring how much information was received and how much time it takes, allows the attacker to find out what encrypted information was received by a web browser.

With software-as-a-service becoming mainstream, more and more applications are delivered to the client through the Web. Unlike a desktop application, a web application is split into browser-side and server-side components. A subset of the application’s internal information flows are inevitably exposed on the network. We show that despite encryption, such a side-channel information leak is a realistic and serious threat to user privacy. Specifically, we found that surprisingly detailed sensitive information is being leaked out from a number of high-profile, top-of-the-line web applications in healthcare, taxation, investment and web search: an eavesdropper can infer the illnesses/medications/surgeries of the user, her family income and investment secrets, despite HTTPS protection; a stranger on the street can glean enterprise employees’ web search queries, despite WPA/WPA2 Wi-Fi encryption. More importantly, the root causes of the problem are some fundamental characteristics of web applications: stateful communication, low entropy input for better interaction, and significant traffic distinctions. As a result, the scope of the problem seems industry-wide. We further present a concrete analysis to demonstrate the challenges of mitigating such a threat, which points to the necessity of a disciplined engineering practice for side-channel mitigations in future web application developments.

No Comments

Please Continue to Hold

Monday, June 21st, 2010

Almost every security measure makes the life of its beneficiary more difficult, and thus those who stand to gain the most are also the most likely to breach security regulations. This subject – the topic of a recent research paper shows that in order to avoid this unfortunate situation, it is better to explain why the security measures are needed.

We found that subjects were significantly more likely to cheat or abandon the task when provided with non-security explanations or a vague security explanation for the delay. However, when subjects were provided more explanation about the threat model and the protection ensured by the delay, they were not more likely to cheat than subjects in the control condition who faced no such delay. Our results thus contribute to the nascent literature on soft paternalistic solutions to security and privacy problems by suggesting that, when security mitigations cannot be made “free” for users, designers may incentivize compliant users’ behavior by intentionally drawing attention to the mitigation itself.

No Comments

New whitepaper available for download

Sunday, December 6th, 2009

Hagai Bar-El’s  technical paper entitled Intra-Vehicle Information Security Framework is available for download at http://www.discretix.com/resources/white_papers.html

No Comments

Please fill the tank, reboot the main CPU and oh don’t forget to clean the windshield.

Monday, November 30th, 2009

According to a recent article in the IEEE Spectrum, the cars we are driving (or at very least our managers) have more electronic control units (ECU) and lines of code than your typical commercial or military aircraft.

The avionics system in the F-22 Raptor, the current U.S. Air Force front line jet fighter, consists of about 1.7 million lines of software code. The F-35 Joint Strike Fighter, scheduled to become operational in 2010, will require about 5.7 million lines of code to operate its onboard systems. And Boeings new 787 Dreamliner, scheduled to be delivered to customers in 2010, requires about 6.5 million lines of software code to operate its avionics and onboard support systems. These are impressive amounts of software, yet if you bought a premium-class automobile recently, it probably contains close to 100 million lines of software code, says Manfred Broy, a professor of informatics at Technical University, Munich, and a leading expert on software in cars

Just like any other software, these millions of lines of code – parked in driveway – have exploitable bugs. A defect density rate of 0.4 defects per thousand lines of code combined with a conservative estimation of 5% of defects that are exploitable yields 2,000 exploitable bugs per 100 million lines of code!!!!!

So where does this leave the average commuter on the way from point A to point B. Probably quite afraid. Many of these bugs are an inevitable back door for hackers, raising serious security concerns.

Faulty lines of code are fact of life and there is not much we can do to pevent them, however some precautions can be taken to ensure that they are not exploited.

  1. Identify malicious code introduction targeted  at using existing exploitable flaws (e.g. secure boot and run time integrity verification).
  2. Allowing valid code images to be revoked and replaced with new, fixed images (renewability mechanisms).
  3. Preventing roll backs to faulty images (again, thru mechanisms like Secure boot and others).

No Comments