JAM36 – NFC development for BlackBerry 10: A whirlwind tour

Here we’ll look at all the tech that is available from you to create solutions. We’ll cover tag reading and writing, P2P and more.  Great to keep in mind that NFC is more than just payment!!!

JAM26 – Demystifying NFC Payment

But – if you’re thinking about getting into payment (or loyalty programs) – this is the session for you.

We’ll cover a few different approaches and talk about everything you need lined up. There are lots of moving pieces involved to make complete secure element / card emulation solution.

Send me an email or tweet @robbieDubya for all of your NFC needs.

Thinking of twitter – Martin @mdwrim and John @jcmrim are people you really should be following if you are into NFC and BlackBerry! #nfcguys

Modified version of “ENIGMA Rotor Set” by flickr user brewbooks.

You’ve found a need to perform some cryptographic operations in your WebWorks application? BlackBerry 10 has a FIPS 140-2 validated library built in…  Here’s the basis of a native extension to allow you to access Security Builder functionality.

The extension is available on our Github repo . Fork it and have a look!

It is a basis – right now – it has SHA1,SHA224,SHA256,SHA384,SHA512 and AES/CBC (all key sizes).

Getting Started

Data

Cryptographic data is binary. You need to be clear on which bytes you want to work with. For this reason the extension accepts data as any of hex, b64 or raw Strings.

Hex is a hexadecimal encoding of the bytes. It’s the safest to work with, and in some ways the easiest. Concatenating two values in hex is way easier than in b64…

Example: { input: { hex: “b0b5cafe” } }

Base 64 [b64] is the preferred encoding of MIME. Some features of the Invocation Framework expect b64 encoded data. Data URIs have their b64 encoded. If a crypto extension can work with b64 – that’s probably going to come in handy.

Example: {input: { b64: “aAz9″ } }

Raw – is just passing the library your String. The big catch here is UTF-8 encoding happening out of your control. If some cipher text contains non-valid UTF-8 encodings – how are you going to marshal that string between JavaScript and c++? You can use it – but trying to use raw with binary data – or non low ASCII languages may bite you later!

Example: { input: { raw: “Montréal” } }

Binary data coming back from the extension is available as all 3 encodings, hex, b64 and raw. (Still not sure that raw is a good idea )

Errors

Errors will be given as a member of the result object. You’ll see this in the sample application;

if ("error" in result) {
    alert(result.error);
    return;
}

Operations

Current operations you can call are;

• hash
• generateKey
• encrypt
• decrypt
• random

hash

Hash expects an object with algorithm (alg) and input data (input) set. Eg:

{
    alg : "sha256",
    input : {
        raw : "r"
    }
};

The typical result is an object with an attribute called output. Output itself is an object containing a hex, b64 and raw encoding of the output. Eg:

{
    "output" : {
        "b64":"RUNJ5CLwUpcZHq0T4h09tSDlq+9SBV5JZLgvshP1k6E=",
        "hex":"454349e422f05297191ead13e21d3db520e5abef52055e4964b82fb213f593a1",
        "raw":"ECIä\"ðR—\u0019\u001e­\u0013â\u001d=µ å«ïR\u0005^Id¸/²\u0013õ“¡"
    }
}

generateKey

Generate key expects an object with algorithm (alg) set. Each individual key generator may expect more values to be set.

generateKey – AES

Generate key – AES – expects the algorithm (alg) and key size (keySize) in bits as an integer to be set. Eg:

{
    alg : "aes",
    keySize : 192
}

AES keys are symmetrical. The data comprising the key is contained in the key attribute of the returned object.

{
    "key" : {
        "b64" : "yzC1yYivNK1VV8gNlYYaSQ==",
        "hex" : "cb30b5c988af34ad5557c80d95861a49",
        "raw" : "Ë0µÉˆ¯4­UWÈ\r•†\u001aI"
    }
}

Generating an AES key is redundant – you could have just used random data of the correct length.

encrypt

Encrypt expects an object with algorithm (alg) set. Each individual encryption implementation may expect more values to be set.

encrypt – AES

Encrypt – AES expects the following values in the parameter object.

• Algorithm (alg)
• Mode (mode) (only CBC is currently implemented)
• Key (key)
• Initialization Vector (IV) (only CBC is current implemented – so this is required)
• Data to encrypt (input)

Eg:

{
    "alg" : "aes",
    "mode" : "cbc",
    "key" : {
        "hex":"cb30b5c988af34ad5557c80d95861a49"
    },
    "input" : {
        "b64":"TW9udHLDqWFsBwcHBwcHBw=="
    },
    "iv" : {
        "hex":"ffeeddccbbaa99887766554433221100"
    }
}

The typical results object contains data in the output attribute. Eg:

{
    "output" : {
        "b64" : "U1fXXVAxdjJf3CLLnF/SVw==",
        "hex" : "5357d75d503176325fdc22cb9c5fd257",
        "raw" : "SW×]P1v2_Ü\"˜_ÒW"
    }
}

decrypt

Decrypt expects an object with algorithm (alg) set. Each individual decryption implementation may expect more values to be set.

decrypt – AES

Decrypt – AES expects and returns the same attributes as encrypt – AES.

random

Random does not expect an algorithm (alg) to be set on input. The original extension author was too lazy to allow the random implementation to be selected.

Random does expect the attribute size to be set. It is an integer indicating the number of random byte that should be returned.

{
    size : 16
}

A response will have the output attribute set to the random data. Eg:

{
    "output" : {
        "b64" : "QGXBbFgY3FPkNwuZHtGRYA==",
        "hex" : "4065c16c5818dc53e4370b991ed19160",
        "raw" : "@eÁlX\u0018ÜSä7\u000b™\u001eё`"
    }
}

Padding

Security Builder GSE does not implement padding algorithms for block ciphers. For this reason you’ll see a PKCS#5 padding implementation in the JavaScript of the sample application.

This padding implementation shows a safe workflow – the function UTF-8 encodes a string before it is padded. It then encodes the combined block using b64.

The padding verification does the reverse – refusing to return the alleged plain text unless the padding verifies.

Remember that padding isn’t really much security… If you try to verify the padding on random bytes the probability that it will pass is great than 1/256…

Let me know what algorithms you need – How are YOU going to protect you and your users’ data? Looking forward to seeing pull requests with great extra functionality!

Did you know that it’s easy to exchange data between your NFC enabled smartphone and your Arduino? It can be arbitrary data too – it does not need to be formatted as NDEF tags or ISO 7816-4 APDUs!

What does it take to get an Arduino that talks with BlackBerry running? Here’s what I used to make a very basic color mixing application that shares colors between the Arduino and the BlackBerry over NFC.

• Some NFC enabled BlackBerry devices. I’m using my Bold 9900s. <3 the keyboard!
• 1 Arduino. I’m using an Arduino Uno R3 (it’s under the shield)
• 1 Adafruit Industries PN532 NFC/RFID shield. A great shield available here: http://adafruit.com/products/789
• 1 BlackBerry application.
• 1 Arduino sketch
• A copy of the Adafruit NFCShield library. Note that I have made modifications to get the functionality that I needed; https://github.com/blackberry/Adafruit_NFCShield_I2C (pull request pending…)
• Imagination. This is the most important ingredient! With these other ingredients you could build… anything! (Hit me up in the comments with your project!)

• Optional: The manual for the PN532. http://www.adafruit.com/datasheets/pn532um.pdf

Arduino Sketch

Here are the guts of my sketch – stripped to the barest functionality… I need to ‘inList’ a passive target and then ‘inDataExchange’. If you can ‘inList’ a target – then you can send data to it…

if (nfc.inListPassiveTarget()) {
    while(true) {
      message[0] = 1; message[1] = r; message[2] = g; message[3] = b;
      uint8_t responseLength = sizeof(message);
      if (nfc.inDataExchange(message,sizeof(message),message,&responseLength)) {
        uint8_t command = message[0];
        switch(command) {
        case 1:
          if (responseLength==4) {
            r = message[1];
            g = message[2];
            b = message[3];
            showColor();
          }
          else {
            //Serial.println("Doesn't seem to be a color...");
          }
          break;
        default:
          ;
        }

The Adafruit samples show you everything you need to know about initializing the class.

The active NFC peer (the Arduino) is responsible for sending data first. You may have to keep on polling your passive peer.

Java

Again – just the basics. You need to create a VirtualISO14443Part4TypeATarget. You have to be aware that the target is only active when your app is in the foreground. The number below is not used by the API. this is an instance of VirtualISO14443Part4TargetCallback.

    emulated = new VirtualISO14443Part4TypeATarget(this, "10451045", null);
    emulated.startEmulation();

Then, in the callback I send the color that has been mixed on the screen (unless the user hasn’t chosen a color recently). The byte array returned from this method is transmitted over NFC.

private byte[] processCommand(byte[] command) {

        if (command == null) {
            return new byte[0];
        }
        int messageType = command[0] & 0xff;
        switch (messageType) {
        case 1:
            if (command.length == 4) {
                int colorIn = (command[1] & 0xff) << 16;
                colorIn |= (command[2] & 0xff) << 8;
                colorIn |= (command[3] & 0xff);

                if (colorIn != color) {
                    if (colorQueued) {

                        byte[] toReturn = new byte[4];
                        toReturn[0] = 1;
                        toReturn[1] = (byte) (color >> 16);
                        toReturn[2] = (byte) (color >> 8);
                        toReturn[3] = (byte) color;

                        return toReturn;

Existing BlackBerry samples and tutorials explain the listener really well.

The Result

Here’s a very short video showing several BlackBerrys sharing colors with the Arduino. I built a paper cube around my LED to try and make it easier to capture on video.

My NFC Slogan

You’re already there! No need to PAIR!

What I’m trying to say in my slogan is this: there are times when you want to be physically at a device and make it do something. To me – NFC feels a little like the crystals that power starship computers in SCI-FI shows. The hero moves them into the right spot; completing the system and saving the day, galaxy and timeline.

There are times that you don’t want to be there either… And there are lots of higher powered RF systems for that…

What Can You Make?

Who will make the first bridge for NFC to XBee that has a cradle form factor?

I’m looking forward to hearing in the comments what you are going to Make!

Imagine if you permanently placed NFC SmartPoster tags on every seat in a stadium. With just a hover of your BlackBerry® smartphone over that tag, a huge array of content and services could be available to your event attendees.

Two pieces would build the deployment, NFC tags and a web server. The tags would be mounted on or near the seat and they wouldn’t have to hold much data. A URL containing the venue and the seating information would be enough. For example:

http://www.stadiumboss.com?ven=yyz&sec=521&lev=4&seat=36

The web server would contextually redirect or fulfill a user’s browser’s request, depending on events that were currently underway. The content of that URL would be in no way static!

If you visited this URL when there was no event occurring, you could show a map highlighting where that seat is. Who is mayor of this seat? Famous people who’ve sat here? How often do fly-balls get caught here? You would even be able to see the view that seat offers. Interactive 3D graphics from the correct point of view related to the game could be shown to a user. (Anyone familiar with the cricket infographics showing where each 4 and 6 was hit during an inning? You could bring it to a whole new level of involvement.) During a sporting event, information as typical as roster information could be a basic offering – but you could alter the content to make it seat specific.

Do you need a drink or assistance to leave your seat? Those could be requested from the same web page. (Steps taken to ensure event participation or attendance would be needed here – but if you used NFC ticketing to enter the event, you’re already done!)

Your BlackBerry smartphone has your exact location – but where’s my buddy Kev? I was sure he was sitting in section 6… If Kev allowed his seating information to be shared when he buzzed in, your smartphone could show you where Kev is seated in relation to you, or even guide you there. The venue could also have way-point tags mounted in the aisles and hall ways – perhaps a ‘convention center’ mode for easy stall mapping?

Back to the 50k Pixel TV

Everything above is dependent on the smartphone screen being aimed at you. People at concerts already hold up their phones – the web page you hit from buzzing into the concert via NFC could be just a single color. And when 50,000 people hold out their phones, those colors will merge into something visceral. The whole crowd could be glowing purple, or those screens could form a giant image.

There’s nothing stopping you from making that image dynamic. (OK, maybe the available bandwidth of the neighboring cell network is a limitation — you don’t want everyone in the stadium trying to access the web at the same time!) Making the color change in sync with the concert to form pictures and video will give you an immersive, living and dynamic 50k pixel TV!

For Users Without NFC

Static information like a seat number doesn’t need to be presented with NFC. Scanning a bar code could achieve the same result. Entering your seat number into your device manually would do the same. Hovering then hitting the web is a smoother user experience.

What Can YOU Build?

If you know exactly where a user is in a large 3D space and all that they have to do is hover their phone to engage with you – what can you build for them? Let us know your ideas in the comments.