Archive for the ‘Uncategorized’ Category

Encrypted Backup

Wednesday, October 6th, 2010

BlackberryThe information people store  securely on their mobile devices (e.g. passwords and PIN codes) not only needs to be stored confidentially, its availability must be protected as well. The confidentiality benefits if the data is not replicated. For example,  even if your password is weak, but an attacker has no access to data encrypted with the password, the password weakness does not assist him.

On the other hand, the availability benefits from replication: if you store the only copy of your data on a device and the device is broken, the data is no longer available. To harmonize the confidentiality and the availability can be a challenge that is easy to fail. Consider the recent case of the extremely popular BlackBerry device.

According to ElcomSoft CEO Vladimir Katalov: All data transmitted between a BlackBerry Enterprise Server and BlackBerry smartphones is encrypted with a highly secure AES or Triple DES algorithm. Unique private encryption keys are generated in a secure, two-way authenticated environment and are assigned to each BlackBerry smartphone user. Even more, to secure information stored on BlackBerry smartphones, password authentication can be made mandatory through the policies of a BlackBerry Enterprise Server (default, password authentication is limited to ten attempts, after which the smartphone’s wiped clean with all its contents erased).

Backup encryption uses AES with a 256-bit key. So far, so good. An AES key is derived from the user-supplied password, and this is where the problem arises.

In short, standard key-derivation function, PBKDF2, is used in a very strange way, to say the least.  Where Apple has used 2,000 iterations in iOS 3.x, and 10,000 iterations in iOS 4.x, BlackBerry uses only one. Another significant shortcoming is that it’s BlackBerry Desktop Software that encrypts data, not the BlackBerry device itself. This means that the data is passed from the device to the computer in a plain, unencrypted form.

There are two problems: the small iteration counter and the exporting of unencrypted data. The main purpose of PBKDF is to slow down the bruteforce attacks by using a large iteration counter and thus by using only one iteration the protection is effectively defeated.

The second problem is probably even more severe while its effect is not that obvious. The usual network security model is that the network is insecure while the endpoints are secure. Historically this was the case, but currently the security situation on the most the most commonly used desktop OS is so bad, that an antivirus is considered a must. In the modern world a security-cautious user knows that he cannot be sure who really “0wns” his desktop, and may decide to keep his the most confidential data on a mobile device.

Apparently, the BlackBerry’s backup procedure renders this strategy ineffective – an attacker who “0wns” user’s desktop gets all the mobile device secrets as well.

No Comments

Malware Enters a New Phase – SCADA Systems Under Attack

Monday, September 27th, 2010
SCADA Systems Under Attack

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.

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

Perils of Provisioning

Monday, July 5th, 2010

In order to securely access high-value services (such as high-definition video content or e-commerce), devices need a so-called “root of trust”—most commonly a key pair for a public-key cryptography scheme. Furthermore, the devices also need an internal root of trust for securing their internal databases; most commonly, this will be a secret key (RKEK, or root key-encryption key) unique to the device and unknown outside it.

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.

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

Automobile Hack – We Should Have Known Better

Tuesday, June 1st, 2010

No one in the automotive security industry could miss the recently published news article titled “Beware of Hackers Controlling Your Automobile”, published here, and a similar essay titled “Car hackers can kill brakes, engine, and more”, which can be found here. In short, it describes how researchers succeeded in taking over a running car, messing with its brakes, lights, data systems, and so on.

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.

No Comments

Attacks always get better; they never get worse – National Security Agency (NSA)

Monday, May 17th, 2010

In this note the authors present the first attack with feasible complexity on the 13-round AES-256. The attack runs in the related-subkey scenario with four related keys, in 2^{76} time, data, and memory.

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).

No Comments

Does size really matter? What does the consumer expect from an iPad, TV and Smartphone?

Wednesday, May 5th, 2010

The success of devices like Apple’s iPad – which reached sales of 1 million devices in less than a month – indicates that mobile devices have crossed into the living room. Conversely, the sheer volume of content available on mobile devices, indicates that the home stereo, TV and VCR have – so to speak – left the building. These seemingly conflicting different trends have massive implications for all stakeholders.

Two Worlds Collide 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….

No Comments