Entries Tagged "cell phones"

Page 21 of 28

Fingerprinting Telephone Calls

This is clever:

The tool is called PinDr0p, and works by analysing the various characteristic noise artifacts left in audio by the different types of voice network—cellular, VoIP etc. For instance, packet loss leaves tiny gaps in audio signals, too brief for the human ear to detect, but quite perceptible to the PinDr0p algorithms. Vishers and others wishing to avoid giving away the origin of a call will often route a call through multiple different network types.

This system can be used to differentiate telephone calls from your bank from telephone calls from someone in Nigeria pretending to be from your bank.

The PinDr0p analysis can’t produce an IP address or geographical location for a given caller, but once it has a few calls via a given route, it can subsequently recognise further calls via the same route with a high degree of accuracy: 97.5 per cent following three calls and almost 100 per cent after five.

Naturally a visher can change routings easily, but even so PinDr0p can potentially reveal details that will reveal a given call as being false. A call which has passed through a Russian cell network and P2P VoIP is unlikely to really be from your high-street bank in the UK, for instance.

Unless your bank is outsourcing its customer support to Russia, of course.

The GIT researchers hope to develop a database of different signatures which would let their system provide a geolocation as well as routing information in time.

Statement from the researchers.

Posted on October 18, 2010 at 6:23 AM • View Comments

Four Irrefutable Security Laws

This list is from Malcolm Harkins, Intel’s chief information security officer, and it’s a good one (from a talk at Forrester’s Security Forum):

  1. Users want to click on things.
  2. Code wants to be wrong.
  3. Services want to be on.
  4. Security features can be used to harm.

His dig at open source software is just plain dumb, though:

Harkins cited mobile apps: “What kind of security do we think is in something that sells for 99 cents? Not much.”

Posted on September 20, 2010 at 6:20 AM • View Comments

Consumerization and Corporate IT Security

If you’re a typical wired American, you’ve got a bunch of tech tools you like and a bunch more you covet. You have a cell phone that can easily text. You’ve got a laptop configured just the way you want it. Maybe you have a Kindle for reading, or an iPad. And when the next new thing comes along, some of you will line up on the first day it’s available.

So why can’t work keep up? Why are you forced to use an unfamiliar, and sometimes outdated, operating system? Why do you need a second laptop, maybe an older and clunkier one? Why do you need a second cell phone with a new interface, or a BlackBerry, when your phone already does e-mail? Or a second BlackBerry tied to corporate e-mail? Why can’t you use the cool stuff you already have?

More and more companies are letting you. They’re giving you an allowance and allowing you to buy whatever laptop you want, and to connect into the corporate network with whatever device you choose. They’re allowing you to use whatever cell phone you have, whatever portable e-mail device you have, whatever you personally need to get your job done. And the security office is freaking.

You can’t blame them, really. Security is hard enough when you have control of the hardware, operating system and software. Lose control of any of those things, and the difficulty goes through the roof. How do you ensure that the employee devices are secure, and have up-to-date security patches? How do you control what goes on them? How do you deal with the tech support issues when they fail? How do you even begin to manage this logistical nightmare? Better to dig your heels in and say “no.”

But security is on the losing end of this argument, and the sooner it realizes that, the better.

The meta-trend here is consumerization: cool technologies show up for the consumer market before they’re available to the business market. Every corporation is under pressure from its employees to allow them to use these new technologies at work, and that pressure is only getting stronger. Younger employees simply aren’t going to stand for using last year’s stuff, and they’re not going to carry around a second laptop. They’re either going to figure out ways around the corporate security rules, or they’re going to take another job with a more trendy company. Either way, senior management is going to tell security to get out of the way. It might even be the CEO, who wants to get to the company’s databases from his brand new iPad, driving the change. Either way, it’s going to be harder and harder to say no.

At the same time, cloud computing makes this easier. More and more, employee computing devices are nothing more than dumb terminals with a browser interface. When corporate e-mail is all webmail, corporate documents are all on GoogleDocs, and when all the specialized applications have a web interface, it’s easier to allow employees to use any up-to-date browser. It’s what companies are already doing with their partners, suppliers, and customers.

Also on the plus side, technology companies have woken up to this trend and—from Microsoft and Cisco on down to the startups—are trying to offer security solutions. Like everything else, it’s a mixed bag: some of them will work and some of them won’t, most of them will need careful configuration to work well, and few of them will get it right. The result is that we’ll muddle through, as usual.

Security is always a tradeoff, and security decisions are often made for non-security reasons. In this case, the right decision is to sacrifice security for convenience and flexibility. Corporations want their employees to be able to work from anywhere, and they’re going to have loosened control over the tools they allow in order to get it.

This essay first appeared as the second half of a point/counterpoint with Marcus Ranum in Information Security Magazine. You can read Marcus’s half here.

Posted on September 7, 2010 at 7:25 AM • View Comments

Security Theater on the Boston T

Since a fatal crash a few years ago, Boston T (their subway) operators have been forbidden from using—or even having—cell phones while on the job. Passengers are encouraged to report violators. But sometimes T operators need to use their official radios on the job, and passengers can’t tell the difference. The solution: orange tape:

The solution? Goodbye, sober black; hello, bright orange, a hue so vivid that, MBTA officials hope, no one will mistake the radios for phones anymore. Workers at the agency’s car barns and garages are in the process of outfitting every handset in the fleet with strips of reflective tape emblazoned with T logos.

[…]

… a small but steady number of hot line tips have been found to be cases of drivers or operators communicating with dispatch by radio, according to video and operations-center call logs.

That is where the electric-orange tape should help, Davey said. Over the past two months, the tape has been applied to handheld radios on about 95 percent of the T’s 1,050 buses (each of which has one handset) and one-fourth of its nearly 210 double-ended Green Line trolleys, which have handsets at each end. The rest of the Green Line and the Orange, Blue, and Red line radios will follow.

Taisha O’Bryant, a Roxbury resident who serves as chairwoman of the T Riders Union, said she is more concerned with the frequency and reliability of bus service than the appearance of bus radios. But she said it is a good thing if a driver or operator can call dispatch in the event of a breakdown or service problem without worrying about appearing to talk on a cellphone, and she hailed the cellphone ban.

Of course, no T operator would ever think of putting bright orange tape on his cell phone. Because if he did that, the passengers would immediately know not to report him.

Posted on August 30, 2010 at 5:31 AM • View Comments

Security Analysis of Smudges on Smart Phone Touch Screens

“Smudge Attacks on Smartphone Touch Screens“:

Abstract: Touch screens are an increasingly common feature on personal computing devices, especially smartphones, where size and user interface advantages accrue from consolidating multiple hardware components (keyboard, number pad, etc.) into a single software definable user interface. Oily residues, or smudges, on the touch screen surface, are one side effect of touches from which frequently used patterns such as a graphical password might be inferred.

In this paper we examine the feasibility of such smudge attacks on touch screens for smartphones, and focus our analysis on the Android password pattern. We first investigate the conditions (e.g., lighting and camera orientation) under which smudges are easily extracted. In the vast majority of settings, partial or complete patterns are easily retrieved. We also emulate usage situations that interfere with pattern identification, and show that pattern smudges continue to be recognizable. Finally, we provide a preliminary analysis of applying the information learned in a smudge attack to guessing an Android password pattern.

Reminds me of similar attacks on alarm and lock keypads.

Posted on August 12, 2010 at 6:48 AM • View Comments

Apple JailBreakMe Vulnerability

Good information from Mikko Hyppönen.

Q: What is this all about?
A: It’s about a site called jailbreakme.com that enables you to Jailbreak your iPhones and iPads just by visiting the site.

Q: So what’s the problem?
A: The problem is that the site uses a zero-day vulnerability to execute code on the device.

Q: How does the vulnerability work?
A: Actually, it’s two vulnerabilities. First one uses a corrupted font embedded in a PDF file to execute code and the second one uses a vulnerability in the kernel to escalate the code execution to unsandboxed root.

Q: How difficult was it to create this exploit?
A: Very difficult.

Q: How difficult would it be for someone else to modify the exploit now that it’s out?
A: Quite easy.

Here’s the JailBreakMe blog.

EDITED TO ADD (8/14): Apple has released a patch. It doesn’t help people with old model iPhones and iPod Touches, or work for people who’ve jailbroken their phones.

EDITED TO ADD (8/15): More info.

Posted on August 10, 2010 at 12:12 PM • View Comments

UAE to Ban BlackBerrys

The United Arab Emirates—Dubai, etc.—is threatening to ban BlackBerrys because they can’t eavesdrop on them.

At the heart of the battle is access to the data transmitted by BlackBerrys. RIM processes the information through a handful of secure Network Operations Centers around the world, meaning that most governments can’t access the data easily on their own. The U.A.E. worries that because of jurisdictional issues, its courts couldn’t compel RIM to turn over secure data from its servers, which are outside the U.A.E. even in a national-security situation, a person familiar with the situation said.

This is a weird story for several reasons:

1. The UAE can’t eavesdrop on BlackBerry traffic because it is encrypted between RIM’s servers and the phones. That makes sense, but conventional e-mail services are no different. Gmail, for example, is encrypted between Google’s servers and the users’ computers. So are most other webmail services. Is the mobile nature of BlackBerrys really that different? Is it really not a problem that any smart phone can access webmail through an encrypted SSL tunnel?

2. This an isolated move in a complicated negotiation between the UAE and RIM.

The U.A.E. ban, due to start Oct. 11, was the result of the “failure of ongoing attempts, dating back to 2007, to bring BlackBerry services in the U.A.E. in line with U.A.E. telecommunications regulations,” the country’s Telecommunications Regulatory Authority said Sunday. The ban doesn’t affect telephone and text-messaging services.

And:

The U.A.E. wanted RIM to locate servers in the country, where it had legal jurisdiction over them; RIM had offered access to the data of 3,000 clients instead, the person said.

There’s no reason to announce the ban over a month before it goes into effect, other than to prod RIM to respond in some way.

3. It’s not obvious who will blink first. RIM has about 500,000 users in the UAE. RIM doesn’t want to lose those subscribers, but the UAE doesn’t want to piss those people off, either. The UAE needs them to work and do business in their country, especially as real estate prices continue to collapse.

4. India, China, and Russia threatened to kick BlackBerrys out for this reason, but relented when RIM agreed to “address concerns,” which is code for “allowed them to eavesdrop.”

Most countries have negotiated agreements with RIM that enable their security agencies to monitor and decipher this traffic. For example, Russia’s two main mobile phone providers, MTS and Vimpelcom, began selling BlackBerrys after they agreed to provide access to the federal security service. “We resolved this question,” Vimpelcom says. “We provided access.”

The launch of BlackBerry service by China Mobile was delayed until RIM negotiated an agreement that enables China to monitor traffic.

Similarly, last week India lifted a threat to ban BlackBerry services after RIM agreed to address concerns.

[…]

Nevertheless, while RIM has declined to comment on the details of its arrangements with any government, it issued an opaque statement on Monday: “RIM respects both the regulatory requirements of government and the security and privacy needs of corporations and consumers.”

How did they do that? Did they put RIM servers in those countries, and allow the government access to the traffic? Did they pipe the raw traffic back to those countries from their servers elsewhere? Did they just promise to turn over any data when asked?

RIM makes a big deal about how secure its users’ data is, but I don’t know how much of that to believe:

RIM said the BlackBerry network was set up so that “no one, including RIM, could access” customer data, which is encrypted from the time it leaves the device. It added that RIM would “simply be unable to accommodate any request” for a key to decrypt the data, since the company doesn’t have the key.

The BlackBerry network is designed “to exclude the capability for RIM or any third party to read encrypted information under any circumstances,” RIM’s statement said. Moreover, the location of BlackBerry’s servers doesn’t matter, the company said, because the data on them can’t be deciphered without a decryption key.

Am I missing something here? RIM isn’t providing a file storage service, where user-encrypted data is stored on its servers. RIM is providing a communications service. While the data is encrypted between RIM’s servers and the BlackBerrys, it has to be encrypted by RIM—so RIM has access to the plaintext.

In any case, RIM has already demonstrated that it has the technical ability to address the UAE’s concerns. Like the apocryphal story about Churchill and Lady Astor, all that’s left is to agree on a price.

5. For the record, I have absolutely no idea what this quote of mine from the Reuters story really means:

“If you want to eavesdrop on your people, then you ban whatever they’re using,” said Bruce Schneier, chief security technology officer at BT. “The basic problem is there’s encryption between the BlackBerries and the servers. We find this issue all around about encryption.”

I hope I wasn’t that incoherent during the phone interview.

EDITED TO ADD (8/5): I might have gotten a do-over with Reuters. On a phone interview yesterday, I said: “RIM’s carefully worded statements about BlackBerry security are designed to make their customers feel better, while giving the company ample room to screw them.” Jonathan Zittrain picks apart one of those statements.

Posted on August 3, 2010 at 11:08 AM • View Comments

AT&T's iPad Security Breach

I didn’t write about the recent security breach that disclosed tens of thousands of e-mail addresses and ICC-IDs of iPad users because, well, there was nothing terribly interesting about it. It was yet another web security breach.

Right after the incident, though, I was being interviewed by a reporter that wanted to know what the ramifications of the breach were. He specifically wanted to know if anything could be done with those ICC-IDs, and if the disclosure of that information was worse than people thought. He didn’t like the answer I gave him, which is that no one knows yet: that it’s too early to know the full effects of that information disclosure, and that both the good guys and the bad guys would be figuring it out in the coming weeks. And, that it’s likely that there were further security implications of the breach.

Seems like there were:

The problem is that ICC-IDs—unique serial numbers that identify each SIM card—can often be converted into IMSIs. While the ICC-ID is nonsecret—it’s often found printed on the boxes of cellphone/SIM bundles—the IMSI is somewhat secret. In theory, knowing an ICC-ID shouldn’t be enough to determine an IMSI. The phone companies do need to know which IMSI corresponds to which ICC-ID, but this should be done by looking up the values in a big database.

In practice, however, many phone companies simply calculate the IMSI from the ICC-ID. This calculation is often very simple indeed, being little more complex than “combine this hard-coded value with the last nine digits of the ICC-ID.” So while the leakage of AT&T’s customers’ ICC-IDs should be harmless, in practice, it could reveal a secret ID.

What can be done with that secret ID? Quite a lot, it turns out. The IMSI is sent by the phone to the network when first signing on to the network; it’s used by the network to figure out which call should be routed where. With someone else’s IMSI, an attacker can determine the person’s name and phone number, and even track his or her position. It also opens the door to active attacks—creating fake cell towers that a victim’s phone will connect to, enabling every call and text message to be eavesdropped.

More to come, I’m sure.

And that’s really the point: we all want to know—right away—the effects of a security vulnerability, but often we don’t and can’t. It takes time before the full effects are known, sometimes a lot of time.

And in related news, the image redaction that went along with some of the breach reporting wasn’t very good.

Posted on June 21, 2010 at 5:27 AM • View Comments

1 … 19 20 21 22 23 … 28

Sidebar photo of Bruce Schneier by Joe MacInnis.