Oscar Sanderson

Presentation from the ‘Customer Loyalty Conference & Expo’

28th September 2012 (Manila, Philippines)

QR Codes are becoming increasingly popular but few people realize just how easy it is to support this technology from an iPhone application.

In this example, I’ll illustrate how to knock together a simple QR Code reader using the open source ZBarSDK. It’s not going to be an ‘All singing, all dancing’ application, but it will be sufficient to illustrate the point.

The following example assumes that you’re already familiar with both XCode and iPhone development.

Step 1: Create a Window-based iPhone application and name it ‘QRReader’

Step 2: Download ZBarSDK

Step 3: Run the ZBarSDK installer and follow the simple instructions for adding the SDK to your XCode project

Step 4: Add the following frameworks to your project:

• QuartzCore.framework
• AVFoundation.framework
• libiconv.dylib
• CoreVideo.framework
• CoreMedia.framework
• AudioToolbox.framework

Step 5: Add the main view to the Application Delegate, as follows:

At this point ZBarSDK is already integrated with the video feed from the camera, but we still need to implement the delegate so that the SDK can notify us when it has managed to detect a QR Code.

The following delegate method should now be added to the Application Delegate:

Step 6: Next we need to create a new UIViewController subclass and call it ‘QRCodeDetail’. This will be used to show the details of the QR Code once it has been read by the main view.

Update the header file to contain the following:

Remember to synthesize the variables:

Finally we update the ‘viewDidLoad’ method:

Step 7: Hook the QRCodeDetail view into the main view

Back in the Application Delegate we need to import our newly created view:

Then we need to update the ‘didFinishPickingMediaWithInfo’ method to load the ‘QRCodeDetail’ view whenever a QR Code is detected:

Step 8: Simply install on an iPhone and enjoy the QR Code Reader.

You can easily generate your own QR Codes here.

It may have taken a while but ’9×9 Killer Sudoku’ games have finally been added to Mister Sudoku.

A total of 451 games were added to the FaceBook and iPhone (v1.2.1) versions of Mister Sudoku earlier this year (March-April).

Almost 12,000 of these games have been played with a total playing time in excess of 200 days.

The average playing time is just over 26 minutes per game and the maximum recorded duration of a single game is 30 hours, which certainly shows a level of determination on the part of the player!

Several years ago when PCI was first being discussed many people within the payments industry were arguing the merits of using Cryptographic Hashes compared to traditional Symmetric Key Encryption.

The most obvious of these benefits seemed to be that the use of Cryptographic Hash algorithms fundamentally addressed the age-old challenge of implementing a robust key management policy, furthermore as these Cryptographic Hash algorithms are One-Way functions they have the added advantage of being totally secure… or do they?

What follows is a simple explanation as to why hashes can collide, and why our inherent need for ‘quick answers’ has tricked us into believing otherwise.

Other topics such as why using hashing on a relatively small data set such as PANs opens the door to brute force attacks, why a ‘salt’ should be protected in a similar fashion to a ‘symmetric key’, will be saved for a another day.

The difference between ‘Intentional’ and ‘Accidental’ Collisions

The web is full of research findings detailing just how difficult it would be to ‘intentionally’ create a hash collision for a modern Cryptographic Hash algorithm such as SHA-256.

A casual Google search using a phrase such as ‘SHA2 collision probability’ will return a multitude of results all explaining how difficult it is to ‘intentionally’ manufacture a collision but few if any that actually explain why collisions can occur by ‘accident’.

This is clearly reassuring as one of the main requirements of any Cryptographic Hash Algorithm is that it must be ‘infeasible for a potential attacker to find two messages with the same hash’.

But this is where our inherent need for ‘quick answers’ gets the better of us. We do a quick search, glance at the results, seeing what we expect or want to see, without taking the time to properly understand and digest the information that is presented to us.

Remember, the focus here is not on the ability of an attacker to ‘intentionally’ find a collision, but moreover the possibility of a collision ‘accidentally’ occurring.

If we were using a Hash Algorithm for the traditional purpose of creating a hash of a document then the security would revolve around the infeasibility of an attacker being able to engineer an ‘intentional’ collision, as we’re using the hash to prevent any tampering of the document contents.

However, in the context of ‘PAN Hashing’ the underlying intention is to render the PAN unreadable without incurring the overheads associated with symmetric key management. As such, the occurrence of collisions would prevent us from being able to prove with absolute certainty that a given ‘hash’ was the result of a given ‘PAN’, something that we would always be able to prove if we encrypted the PAN using a Symmetric algorithm (i.e. AES).

Why One-Way algorithms are designed to Collide

The real irony when discussing hash collisions lies in what is perceived to be one of the biggest strengths of Cryptographic Hash algorithms, the fact that they are One-Way irreversible algorithms.

Did you ever take the time to contemplate how these algorithms ensure that they are One-Way?

We don’t need to delve into any advanced mathematics here, as a simple example will suffice. Let’s consider the following One-Way function:

C = (A + B) MOD 10

The function is One-Way / Irreversible because simply by knowing A and C it is not possible to deduce B, and likewise by knowing B and C it is not possible to deduce A, as illustrated by the following examples:

A=5, C=9 –> B=4,14,24,34, …

B=2, C=1 –> A=9,19,29,39, …

The reason that the function is One-Way / Irreversible is quite simple… it produces ‘collisions’!

If you take a look at standard Cryptographic Hash Algorithms such as the SHA family of hashes, you’ll see the same technique (i.e. Addition modulo 2ⁿ) being used to ensure that the algorithm is One-Way / Irreversible.

Conclusion

Hopefully by this point you’re convinced that Cryptographic Hash Algorithms such as the SHA family do collide and that this is an intended and fundamental part of their design.

Whilst the likelihood of two or more valid PANs colliding and resulting in the same hash is probably extremely low, the point remains that it could theoretically happen.

Before using a Cryptographic Hash algorithm as a means of providing ‘pseudo encryption’ of PANs, it is important to first understand the fundamental properties of the algorithm and what it was originally intended for.

‘Mister Sudoku’ is now available for both the iPhone and Facebook.

The latest version (v1.0.1) of the iPhone application can be downloaded from the AppStore by clicking on the attached screenshot.

The Facebook version can be accessed directly from your Web Browser by simply adding the ‘Mister Sudoku’ application from within Facebook.

Mister Sudoku gives you access to a multitude of Sudoku game types including the popular Jigsaw and Killer variants. With varying levels of difficulty and sizes there are games for everyone and every occasion.

One of the distinctive features of Mister Sudoku is that you can seamlessly switch between Facebook and the iPhone whilst maintaining a single consolidated scoreboard. All that is required is to enable ‘Facebook Connect’ from within the iPhone application and all your scores will be automatically synchronized with Facebook.

The latest version includes a pack/unpack benchmarking module, along with sample MSVC 6.0 project files. The benchmark test is the same as the one published by jPOS.

The benchmarks were run on a Dell Inspiron 6000 laptop (Intel Pentium M – 2.00GHz).

In ‘Static Memory’ mode it is possible to perform in excess of 130,000 pack/unpack operations per second, as shown by the following screenshot: 

 The throughput in ‘Dynamic Memory’ mode is lower but still manages just under 100,000 pack/unpack operations per second, as shown by the following screenshot:

See the ISO 8583 page for more details…

I’ve just released an updated version (v0.0.2) that includes a 1987 message handler… See the ISO 8583 page for more details…

It’s been almost two years since I wrote my ISO 8583 library and I’ve finally managed to get around to publishing it. Since its original conception back in 2005 I’ve made a few minor changes, mainly with regards to naming conventions and to facilitate the addition of different version handlers in the near future.

This version includes the ISO 8583:1993 (binary) message handler.

Check out the ISO 8583 page for further details…