Tuesday, 27 May 2014

Like to know more about how Users interact with your Apps?

I'm keen to ensure app users get the best possible experience, and my colleague Marcin Zyga recently demonstrated his use of Flurry for gathering stats on how users interact with applications he's developed.

Flurry looks good, and Marcin's careful and considered use of the tool means he's able to get some useful actionable insights from the data he's collecting, but being more familiar with Google Analytics I thought I'd see what Google (and others) are doing in this space.

Luckily Sylvain Gauchet over at Apptamin Blog has already done much of the heavily lifting for me by conducting a very useful round up of some of the main players in this space as can be seen in his blog post here, which is definitely worth a read. Thanks for that Sylvain. ;)

Thursday, 22 May 2014

Some Thoughts on Beacon Security and Spoof Proofing your Beacon Constellation

Two of our mobile technology specialists attended the iBeacon hackathon in London last month. I was unfortunately unable to attend due to a prior commitment, but fortunately the guys gave me a fairly detailed briefing on their experiences and the hot topics under discussion (more on this in a forthcoming post).

You'll probably be unsurprised to hear that device security was a key talking point at the event, and the issue is perceived to present a significant challenge when deploying and maintaining a beacon based solution.

While it's certainly true that devices have their weaknesses (some more than others), and spoofing is a fairly trivial exercise, I'm left wondering if security really will be a significant issue for many common use cases.

Consider the typical retail deployment: a number of beacons are installed within a retail space, their primary function being to geofence particular locations within the store. It's difficult to see any financial advantage that could be gained by hacking or spoofing these beacons, except perhaps by the hacker somehow holding the retailer to ransom - though I think this is a bit of a stretch. I think it more likely that any such attack would be a targeted act of vandalism, either by parties holding a grudge against the retailer, or by bored mallrats with an interest in hacking.

I suspect current legislation on misuse of computer systems would cover such an attack, at least in the UK, but I'd be interested to know the exact legal position. A candidate for some light bedtime reading perhaps.

Spoof Proofing

I don't think spoof proofing is actually possible given the current BLE/iBeacon spec, but there are things we can do to help protect our systems.

If the retailer is interested in deploying countermeasures against a spoofing attack, then the effect could be somewhat mitigated if the back end of a beacon aware application allowed for quarantining compromised beacons.

When a mobile application makes a request to the backend passing the identity of a beacon that's marked as compromised (either spoofed or hacked), the backend would provide an error code to the mobile application which would cause the application to effectively ignore the beacon. This would prevent the application from triggering behaviour out of context (displaying a catalogue of this seasons new fashions while in the food court, for example).

So how do we quarantine a beacon in the first place? I'm thinking we should be able to detect spoofing attempts by monitoring the cadence of the various advertising signals within our beacon constellation, and alerting on any event that falls outside the "normal" pattern.

We'd collect this data via a small network of dedicated monitoring devices within the store (the Raspberry Pi springs to mind as an inexpensive test bed for this approach). Supplementing the fixed monitoring devices with monitoring apps running in the background on mobile devices used by staff could give enhanced coverage.

Over time we should be able to build up a detailed and accurate picture of Bluetooth traffic within the store and unusual events should be simple to spot. If we have an alert on a particular device, we put that device in quarantine until it can be verified that there is no threat, at which point we'd re-enable it via the management back end (perhaps after giving it an all-new identity).

It may be that sophisticated attacks could defeat such a solution, but if it can be deployed in a cost effective way, and is deployed in conjunction with effective physical security, I believe it could provide a reasonable degree of protection. Whether the benefits are significant enough to warrant deployment obviously depends on the retailer's valuation of the commercial damage an attack would cause, and the cost of deployment and maintenance of the solution.

Obviously such a solution would be potentially useful in non-retail environments too.

Beyond Simple Geofencing - Initiating and Securing a Payment Workflow 

One of the beacon use cases that most interests me is the concept of a beacon based payment terminal, for example an iPad, that can be used for "queue busting" within a store. The iPad would be broadcasting in "immediate" mode, so that a device running the retailer's in store shopping app could discover it when in very close proximity.

Beacon discovery would start a handshaking process between the two devices and the sales assistant and customer would work through a process to take payment for the content of the customer's shopping basket. In this case beacon security is a fairly trivial issue, as security would be built into the workflow between the mobile payment terminal and the customer's phone.

Once the handshake was complete the devices would be communicating with the same backend over a secure connection and payment could be via a credit or store card account, some third party system such as PayPal, or even NFC if Apple ever decide to support it.

There may already be such systems out there in the wild, but if not it's surely only a matter of time... watch this space. ;)