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.

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.

The challenge with all of these secrets is that they have to get to the device, usually at some point during its manufacturing (or when it is activated). But to get a secret from one place to another, we need a secure channel; and the only two ways known to establish such a channel are either physical security or cryptographic security. In this case, physical security implies a secure assembly plant, which raises costs. Cryptographic security, on the other hand, requires a secret key to be shared between the sender and recipient—which then becomes a chicken-and-egg problem.

The Discretix solution to provisioning the device RKEK involves use of the digital random-bit generator (DRBG) built into CryptoCell. The DRBG is built according to NIST cryptographic standards (NIST SP800-90), and produces truly random, cryptographic-strength random bit vectors. Discretix’ provisioning tools use this DRBG on the manufacturing line in order to produce the per-device key and program it securely into the device’s non-volatile memory.

Discretix’ solution to provisioning OEM-supplied assets (such as key pairs for enabling high-value services) is more complicated. The foundation for Discretix’ solution is a 128-bit secret embedded in every CryptoCell; this secret is combined with an OEM public key in order to produce a per-OEM provisioning key. Since the secret is not itself known to OEMs, these provisioning keys can only be computed by the manufacturer of the CryptoCell-enabled chip (or by the CryptoCell device itself); since the same key is used for code signing, one OEM cannot reproduce another OEM’s key. Even more importantly, no-one else—including any eavesdroppers on communication lines, or untrustworthy assembly-plant employees—can compute these keys. These keys are then used by the OEM to encrypt and sign their secure assets; the encrypted assets are recorded in the device’s memory, and the embedded CryptoCell can verify their authenticity and decrypt them when access to the services is required.

The end result from all these mechanisms is a secure solution for provisioning a device with all the secrets it needs for high-value services.

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.

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.

As alarming and and serious as this is, it should not come as a surprise.

Just before we begin to discuss the attack, there is one fact that should be emphasized, which is not emphasized in the articles: the hack, while carried out from a vehicle driving at a short distance, did not actually involve taking over the target vehicle without the driver’s consent, e.g., over a communication link. Carrying out the attack required that the attackers connect, physically, to the CAN bus of the car. They did it with a laptop that was physically connected to the CAN bus inside the target car, with said laptop also maintaining the wireless connectivity to the other car (from which the attacks were launched). As of today, there is no clear way for an attacker to reach the CAN bus from outside the car using wireless connectivity alone.

This should not make us feel much better, though. The fact that no such clear way is known today does not mean that such a way will not be found tomorrow. Consider that paths need not be “formal”, designed, ones. If there is an application in the car that connects on one end to a wireless network and on the other end to the CAN bus, and if this application has some flaw that allows it to be properly exploited, then the path from the wireless network to the CAN bus can be formed without having to install a laptop (or any other device) within the physical premise of the car. So keep using your car, but keep reading the news as well.

What I wanted to discuss is why this attack should not come by as a surprise to anyone. It seems as we make a same mistake again; a mistake we’ve made in the past, and thus should have known better. The mistake is designing a system with a hard external shell, which is very soft in the inside. We already tried this with networks on the Internet. Back in the nineties, it was widely accepted by most IT people that as long as a firewall is installed to isolate the corporate network from the Internet, not much else needs to be done, e.g., to protect internal components from each other. As long as the bad guys are kept out, why do we need to fortify what’s in? We then learned that firewalls can occasionally be bypassed, and that most attacks involve insider components anyway. Every network security manager knows by now that while a firewall is necessary, internal hosts need to be hardened, almost as if the firewall did not exist.

When designing car networks, it seems as we forgot what we learned when designing corporate networks. The CAN bus has no meaningful security of its own, and most applications using it are not any wiser. Instead, the entire vehicular system derives its security from the fact that the bus only spans the physical embodiment of the car, where all components are presumably cooperative and non-evil. As soon as an internal component becomes evil, either because it was taken over by an attacker exploiting a flaw in it, or, as was just demonstrated, because it was planted by someone else with different interests and morals, the system breaks apart.

What can be done? Use our past experience and wisdom to build security in the car network as we do in the corporate network. Entities speaking to each other need to be securely authenticated, and some access policy needs to be enforced. Design the internal network as if outsiders can get in, because one day they will.

In a paper of mine, Intra-Vehicle Information Security Framework, I discuss a system that, among several other security features, provides for secure messaging between car components. Secure messaging would allow the brakes system to be able to tell signals coming from its valid controllers apart from signals coming from an outsider’s laptop, even if this laptop can access the CAN bus. As opposed to other secure messaging systems, it was built for low latency even on resource-constrained devices, to suit the typical vehicular use-cases.

We got very smart in network security over the past twenty years. We already paid the price of learning from experience. Let us not re-pay it; especially where the cost might be higher.

Taken with permission from Hagai’s Blog.

It is still far from a really practical attack on the full cipher, but once again shows that proper cryptographic hygiene should be used, that is the keys must be derived with a proper key derivation function (KDF) and not by “xoring with a constant”.

While speaking about cryptographic hygiene, let me remind everyone that the CBC mode of operation requires random IV (and random does not mean the previous one plus 1).

It’s not only that Apple have brought a mobile device into the living room. Implicit in the usage of the device is the expectation of a typical mobile subscriber viz personalization, on-demand, multi-function etc. Using an iPad the subscriber defines his entertainment schedule, not the service provider, the cable operator or broadcaster. The subscriber gets to decide if the device is an eBook reader, a TV or computer. In this sense the iPad is merely a manifestation of a far larger trends, namely that of personalization.

On the other hand the user want to stay connected on the move, with access to the same content outside of the home. Electronic books, games, HD video and TV are all being pushed to the mobile device. The subscriber now gets TV via the internet, books from the MNO (or even the author) and videos directly from the studios. Mobility is only part of the picture, the larger story is a breakdown of the traditional value chain. And once these service providers have developed a direct relationship with the subscriber, for the same effort they can push the content to his iPad, Home Network, TV or any other connected device. Again mobility is just a manifestation of disintermediation – explained by Wikipedia as a term in economics meaning the removal of intermediaries in a supply chain or “cutting out the middleman” (for a good example of disintermediation – look no further than Wikipedia).

Disintermediation and personalization converge in the connected device. Packaged correctly they have the power to turn existing relationships upside-down and grant the user more freedom than ever before. Naturally as traditional subscriber relationships breakdown and content is pushed to different devices the implications for security and content protection are mindboggling.

Watch this space for more information, or should I say, don’t touch that dial….

Click here to read about the risks posed to smartphones and the need for security in open operating systems: http://wirelessweek.com/Articles/2010/03/Devices-Secure-Open-OS-Smartphones/

Modern electronic cryptographic devices in addition to the acoustic side-channel of their mechanical predecessors, leak information by means of variation of their power consumption and electro-magnetic radiation. Aside from passively analyzing side-effects of cryptographic computations, an attacker can also actively subvert the environment to introduce faults into the computation. This approach is known as a “fault attack”.

Although the side-channel attacks on a general purpose CPU (especially, timing attacks) were known for a long time, the fault attacks were limited to very small devices, primarily, smart cards.

Recently, a team of researchers from Italy http://eprint.iacr.org/2010/130 presented a fault injection attack against cryptographic software run on an ARM9 general purpose CPU.

Fault injection attacks have proven in recent times a powerful tool to exploit implementative weaknesses of robust cryptographic algorithms. A number of different techniques aimed at disturbing the computation of a cryptographic primitive have been devised, and have been successfully employed to leak secret information inferring it from the erroneous results. In particular, many of these techniques involve directly tampering with the computing device to alter the content of the embedded memory, e.g. through irradiating it with laser beams.

In this contribution we present a low-cost, non-invasive and effective technique to inject faults in an ARM9 general purpose CPU through lowering its feeding voltage. This is the first result available in fault attacks literature to attack a software implementation of a cryptosystem running on a full fledged CPU with a complete operating system. The platform under consideration (an ARM9 CPU running a full Linux 2.6 kernel) is widely used in mobile computing devices such as smartphones, gaming platforms and network appliances.

At first, we validate the effectiveness of the proposed fault model to lead practical attacks to implementations of RSA and AES cryptosystems, using techniques known in open literature. Then we devised two new attack techniques, one for each cryptosystem. The attack to AES is able to retrieve all the round keys regardless both their derivation strategy and the number of rounds. A known ciphertext attack to RSA encryption has been devised: the plaintext is retrieved knowing the result of a correct and a faulty encryption of the same plaintext, and assuming the fault corrupts the public key exponent. Through experimental validation, we show that we can break any AES with roughly 4 kb of ciphertext, RSA encryption with 3 to 5 faults and RSA signature with 1 to 2 faults.