Read more about a novel way of addressing this problem. Learn how to increase recall rates dramatically, make authentication at least twice as fast, and boost security at the same time.

Phishers are only successful if
(a) they manage to trick their intended victims; and
(b) the resulting actions of these victims are beneficial to the fraudsters.
Both conditions are necessary.

Typical security measures aim to mitigate the threat of spoofing by addressing the first condition, i.e., by avoiding that intended victims are tricked. This is done by conveying security and risk to users – e.g., using locks and conveying recognizable URLs to represent security, and by using warnings and requiring unusual user action to represent risk. This general approach is not very effective, as it relies on users paying close attention to subtle cues and to not act out of habit. The approach we take to achieve this goal relies on undermining the second condition for success for phishers, namely that the resulting actions of victims are beneficial to the fraudsters. The simple but somewhat ironic beauty of the approach we introduce is that it turns reflexive user behavior from being a danger (as it is today) to being a distinct advantage.

Read more about a novel way of addressing this problem or download our proof-of-concept browser to experience it first hand! But first, get ready to challenge traditional thinking.

For example, the traditional anti-virus paradigm is poorly suited to mobile devices due to the battery power constraints these have. It is based on constant screening of events. This screening gets increasingly expensive (between logarithmically and linearly) with an increasing number of threats. By cost, I mean computational effort — and therefore, use of battery power. That is one thing that makes handsets very different from regular computers. You do not want to drain your battery just an hour away from home? Thought so. So we need an alternative mobile malware defense. And we need it before the onslaught of mobile malware hits us — early 2013 is my estimate of when that will happen.

How about entering passwords on your phone? Not so fun, right? While text in emails and SMSes will autocorrect and autocomplete, you are not so lucky with passwords. Unless you use a password manager, but that has security drawbacks. But there are ways in which we can use these nice features and still maintain security. (Read more about my proposal of how to do that.)

The ways in which handsets are different from PCs are not only technical. Mobile devices are used in a different way than traditional computers are. For example, they are “more social” – which does not bode well for security. So the new form factor also affects the threat model.

But not everything about is a potential drawback on handsets. Sometimes, the ways in which handsets are different may help us design better security. For example, the rich input that handsets have access to (including accelerometer input and GPS coordinates) can improve authentication decisions. Your phone knows that it is where it normally is at this time of the day, that you just completed normal-length phone calls with a set of people you normally talk to on the phone — and sent an SMS to your mom. Of course it is you. No password needed.

With different constraints, new solutions are needed. By recognizing that a mobile device is not just a smaller computer, it is possible to design suitable protection techniques.

Here is the experiment we designed, in a nutshell.

Imagine a camera that sells for $750 new, and I offer one for sale on Craigslist for $250. Only used for a few weeks, in perfect condition. Good deal, right? But what if I instead were to ask $750 (or more) for it used? Not so hot, you might say. It makes more sense for you to buy it in the store. You would not bother contacting me.

But fraudsters would.

They may contact me and ask to buy it – even at a premium. They will tell me where to ship it, and they will send me a payment. Or rather: something that looks like a payment to a would-be victim, who would not realize that it really was not a payment until after the camera was shipped.

We used that approach to “filter away” everybody but fraudsters. Then, we interacted with them, as a “normal” victim might, and recorded what happened. We learnt that most of them are indeed in Nigeria. They do not use technically “advanced” tricks like email spoofing, as most phishers would have. And many of them were bullies — which must mean that bullying is a winning strategy! Read more about our findings.

Google made ingenious changes to their code within days of learning of the problem: simply make the advertisement an anonymous iframe, preventing it to be read. But there are still several service providers that are vulnerable to our attack.

Similarly, when I started working on understanding the threat of phishing around year 2000, the reaction I got was almost always “That won’t happen, and if it does, there will be one article about it in the Times, and then everybody will know to look for the SSL lock.” I don’t want to gloat, but we know now that it is just not that simple. To prove that to people then, I started designing experiments. For quite some time, these experiments were informal and were never published — I never got IRB approval. Later, I carried out more rigorous experiments, and with approval from IRB and legal — examples are my phishing experiments on FaceBook users and eBay users, and on how malware might spread over social networks. That was to show how people really react, to prove my point. Soon afterwards, phishing was a common word in media, and no point needed to be proven. But there was still a need for experiments — to understand the exact nature of the threat, how people react to it, and to test how people may react to yet non-existent threats. From then on, the user was always a part of the picture for me.

Recognizing constraints of reality — whether technological, legal, social or cultural — is a necessary part of being able to formulate the right questions. Understanding just one of these dimensions is insufficient: For security to be relevant, it needs to be holistic, considering all dimensions. Speaking of which, I think it is actually possible to take a big bite out of web and app spoofing – if we are willing to challenge our preconceived notions!

In the end, Intel cancelled the processor identity plans. Unfortunately, I would say, given how fraud has mushroomed. As a result, machines are identified in other ways – but not so well.

Cookies are used to identify repeat visitors, but as cookies are often erased and often stolen, their value is limited. Many companies identify machines by objects in their browser cache, and publicly readable machine configurations – such as what browser and operating system you use, and what your screen resolution is. Good guys are profiled. But crooks dodge the checks or steal and use other people’s machine identities.

We desperately need a reliable way of identifying devices.

Fortunately, this is possible. And all from software to boot.

Let me explain how. Many laptops and all cell phones and tablets use so-called NAND flash memory for system specific or general storage. NAND flash is a tricky thing: it is quite error prone, and as the memory is used, some good cells turn bad. But bad cells never turn good. They are broken. NAND flash can actually lose data integrity just by reading its contents, but such errors can be corrected using error-correcting codes. When a block gets permanent bit errors, it is simply marked as bad, and avoided onwards. There are actually several of these bad blocks as the chip leaves the factory!

Broken stuff?!? That is great!

Imagine that we select a particular block to store an identity in. Say, block 1024. When a device is first introduced, it may not have any errors in this block, but no problem. We will write and erase it thousands and thousands of times, which takes a few seconds. This creates errors. If we do not get enough, we continue a bit longer. (We then put this block on the Bad Blocks list to make sure it is not used by mistake by the file system or other processes. We will always be able to access the block even though it is on the list.)

We can easily check what the errors are. We set all the bits in the block to zero, then read the block. Some cells will be broken and will result in 1s when we read them. We then set them all to ones and read them. Some will still come out as 0s. We have now found the errors! (No need for error-correcting codes; in fact, we will read and write “raw”, which is possible since all of this will be done on OS level.)

When a machine comes back, what do we do? Same again. Set all bits in block 1024 to zero, read them back. Set them all to one, read them back. That’s the identity. Sure, it won’t encode your name or your phone number, but it will be unique.

In other words, we recognize devices (or rather: their flash memory) by their defects. Very much like humans recognize faces: by their defects (or deviations from the “norm”) … a bigger nose, a bit too bushy eyebrows, bigger cheeks.

And the nice twist is that if an attacker manages to read your device identity, he cannot inscribe it into his own device. Yes, he can create errors – like we did. But he cannot control where in the block they occur as this relies solely on microscopic manufacturing defects in the silicon. Nor can the attacker overwrite the device identity of your device even if he runs his software on it. Sure, he can imprint more errors on the block, much like a burglar placing a new fingerprint on top of an existing one (good forensics software will still be able to match both fingerprints). Worst case: The attacker places a thousand “fingerprints” on top of each other leaving the block completely trashed. Tough luck. The identity is gone, but at least the machine has not been imprinted with a false identity.

If we run a secure boot or a reliable software-based attestation scheme before we ID a device, we know that there is no active malware that may modify the report that results from reading the machine identity. So we know that the reading actually comes from the intended block, and that it was done correctly.

We know the identity. No guessing.

Friendly fraud is when an unauthorized payment is performed by a friend or family member of the account holder. Surprisingly to many, this is one of the most common types of fraud. It causes great losses to merchants in the form of chargebacks, administrative costs to financial service providers, and losses (when not discovered) and frustration to consumers.

Traditional security mechanisms, such as PINs and passwords, do not address the problem well. This is due to the absence of use of these mechanisms, common account sharing, and the ease for fraudsters close to a victim to access accounts using password reset techniques. (These are often based on knowing facts that friends and family members commonly know about each other.)

Instead of thinking of security in terms of cryptography, it is more effective in this case to consider the psychology that underlies the problem. Leveraging on two very common emotions — guilt, and the fear of being found out — we can make headway to address friendly fraud. The image below gives a glimpse of the approach — to read more, see my recent SecurityWeek blog.

In contrast, the “traditional” security approach might have been: Tell people not to share passwords; Make people change their passwords more often; Clarify that account sharing is against the terms of service (on page 156 of the EULA that nobody reads.) It is doubtful that either of those approaches would help.

]]> http://www.markus-jakobsson.com/friendly-frau/feed 0