Author at Infinum

Android Fingerprint Security

Ana Baotic — Thu, 07 Jul 2016 14:40:00 +0000

Security has always been a crucial part of mobile development, and getting it right is no small feat. Smartphones started out using 4-digit PIN codes that took 10,000 tries at most to crack. Then came the lock pattern that raised the bar to astonishing 389,112 distinct patterns, although basic human nature drastically lowers this number.

Unlike PINs and lock patterns, fingerprint authentication is light-years ahead. One’s fingerprint is truly unique and cannot be guessed. This technology is becoming increasingly popular on consumer devices, and with Marshmallow it’s easier than ever to implement it in your app.

Then

Apart from iOS Touch ID which we already wrote about, early implementations of fingerprint scanning on Android were not adequate. Every vendor had their unique approach to security and implementation of the process and, most importantly, to how the user’s private data is stored.

Now

With Marshmallow came the long awaited native support for fingerprint authentication via a standard API. Android developers were finally allowed to implement fingerprint-based authentication for unlocking devices, Play Store and Android Pay purchases, as well as providing custom authentication in security-heavy applications like mobile banking.

First made available on the Nexus 5X and Nexus 6P, Google introduced the fast and secure Nexus Imprint fingerprint sensor which also brought along the first implementation of the Android 6.0 Marshmallow fingerprint sensor API. Fingerprints are recognized in less than 600 milliseconds, providing fast and comfortable user experience.

Fingerprint storage security

Most storage strategies on Android are insecure, especially when you consider the possibility of root access. But Google has made a noteworthy step in the right direction by moving all print data manipulation to the Trusted Execution Environment (TEE) and providing strict guidelines for fingerprint data storage that manufacturers must follow.

TEE

TEE is a secure area of the smartphone’s main processor. It guarantees confidentiality and integrity of the code and data loaded inside. This separation enables security and protection from hacks, malware and root access.

All fingerprint data manipulation is performed within TEE
All fingerprint data must be secured within sensor hardware or trusted memory so that images of your fingerprint are inaccessible
Fingerprint data can be stored on the file system only in encrypted form, regardless of whether the file system itself is encrypted or not
Removal of the user must result in removal of the user’s existing fingerprint data
Root access must not compromise fingerprint data

Fingerprint templates

Fingerprint templates are the processed versions of raw fingerprint data.
In order to comply with guidelines they must be cryptographically authenticated. This means they have to be signed with a private, device-specific key and enough additional data (an absolute file system path, finger ID and group) that will unequivocally define their binding relationship. As a result, these templates are rendered useless if copied to another device or another user tries to use them.

Finally, fingerprint data is not backed up to the user’s computer or Google’s servers. It is not synced, shared or used by any other app on your device nor does it ever leave your device. The only information apps receive is whether a fingerprint has been verified or not. This also means the user has to set up fingerprint authentication on each new device.

Sounds good, how do I implement it?

Fingerprint authentication in nothing more than data encryption. It involves a key, a cipher that performs encryption, and a fingerprint manager that handles the whole process. From a developer’s standpoint, the process is somewhat extensive but it consists of relatively simple steps.

Request fingerprint authentication permission within the project’s AndroidManifest file.

Enable any lock screen security mechanism (PIN, pattern or password).

Create an instance of the FingerprintManager.

Use a Keystore instance to gain access to the Android Keystore container.

Generate an encryption key using the KeyGenerator class and store it in the Keystore container.

Initialise an instance of the Cipher class using the previously generated encryption key.

Use the Cipher instance to create a CryptoObject and assign it to the instantiated FingerprintManager.

Call the authenticate() method of the FingerprintManager instance.

Handle callbacks on completion of a successful authentication, providing access to protected content or functionality.

Google has supplied a comprehensive sample for fingerprint authentication, and there are several tutorials available online that can get you on your way.

Android’s fingerprint authentication and backing implementation have been designed and executed really well. Using it as a possession element of any form of multi-factor authentication is more than enough to provide you with a fast, reliable and secure authentication experience.

You can hear us talk about fingerprint security and best practices in app security at the 360andev conference in Denver, CO.

So where’s the catch?

There is only one and it’s basically the same flaw all other methods have; fingerprint authentication has a single point of failure. As attractive as using your fingers for unlocking your device is, you leave them everywhere. A prospective attacker can lift your fingerprint without much hassle, and then use it to get control of your device and apps.

Unfortunately, unlike passwords, your fingerprints are something you obviously cannot change.

The post Android Fingerprint Security appeared first on Infinum.

Simple Server-Client Syncing for Mobile Apps Using Couchbase Mobile

Ana Baotic — Thu, 17 Jul 2014 09:20:00 +0000

If you’re developing a content rich application that synchronizes data from server to smartphone and needs to work offline, this is the article for you.

Every once in a while, you end up working on a project that throws you out of your comfort zone and requires some heavy duty learning.

For me, it was a seemingly simple project that required things like data replication and high availability, things I vaguely remember from my college days.
After some exploring, I came across Couchbase Mobile, a framework that offers support for mobile app development and covers all of the requirements.

Couchbase Mobile has two major parts:

Couchbase Lite – an embedded, schemaless, JSON database
Sync Gateway – a mechanism to sync data to and from the server

NOSQL

Couchbase Lite is a NOSQL database, which means that there’s no schema or a predefined data structure. It’s a document store and the documents are JSON objects. It also means that you don’t need to worry about structural changes in the data, since there’s little structure to begin with. This allows for great flexibility and little maintenance.

VIEWS

If you need to build reports, aggregate and join documents, or have different representations of the data, you can use views. Views are defined in JavaScript. They are built dynamically and don’t affect the underlying data, so you can have as many as you like.

DISTRIBUTION

Couchbase’s distribution system is incredibly complex and very powerful. It has several main characteristics, and you can fine tune your app to use any or all of them:

Master → Slave replication
Master Master replication
Filtered Replication
Incremental and bi-directional replication
Conflict management

NETWORK AVAILABILITY

Additionally, you don’t need to take care of the changes in the network availability. The underlying network listener in the library monitors the changes, and pauses and resumes whatever replication you have running, leaving you ample space to notify the user of the current network status.

Replication itself can be one-shot or continuous. If you want to say when and what needs to be synced to or from the host, you will use one-shot replication. On the other hand, if the requirements say that data should be synced anytime a change occurs, then continuous replication is the way to go. Both replications will download the same data, but keeping continuous replication running requires minimal data traffic, in my case less than 100 kB/h.

How do I implement it?

After we’ve covered the basics, let’s see just how simple setting up an app with Couchbase Lite is.
The official getting started pages are quite detailed and easy to follow.
In the following example, I use the Cloudant service as the backend for my demo application, but you can setup your own host with CouchDb on it.

Here is a code example of the bare minimum needed to implement bidirectional replication from your Android application;

1. Add the repository location to the application’s root build.gradle file

buildscript {
    repositories {
        mavenCentral()
        maven {
            url "http://files.couchbase.com/maven2/"
        }
        mavenLocal()
    }
    dependencies {
        classpath &#8217;com.android.tools.build:gradle:0.9.+&#8217;
    }
}

allprojects {
    repositories {
        mavenCentral()
        maven {
            url "http://files.couchbase.com/maven2/"
        }
    }
}

2. Add the dependency to the module’s build.gradle file

compile &#8217;com.couchbase.lite:couchbase-lite-android:1.0.0&#8217;

3. Add the following code to your application’s main activity or fragment

//initialise the database
 protected void initDB() throws IOException, CouchbaseLiteException {
        // create the database manager with default options
        Manager manager = new Manager(new AndroidContext(MainActivity.this), Manager.DEFAULT_OPTIONS);

        // get or create the database with the provided name
        database = manager.getDatabase("demodb");

        // add a change listener
        database.addChangeListener(databaseListener);
    }

//start bi-directional syncing
protected void startSync() {

        URL syncUrl;
        try {
            syncUrl = new URL("https://username:password" +
                    "@username.cloudant.com/demodb");
        } catch (MalformedURLException e) {
            throw new RuntimeException(e);
        }

        // server - client 
        Replication pullReplication = database.createPullReplication(syncUrl);
        pullReplication.setContinuous(true);

        // client - server 
        Replication pushReplication = database.createPushReplication(syncUrl);
        pushReplication.setContinuous(true);

        // replication listeners
        pullReplication.addChangeListener(pullReplicationListener);
        pushReplication.addChangeListener(pushReplicationListener);

        // start both replications
        pullReplication.start();
        pushReplication.start();

    }

//call those methods in the onCreate
@Override
    protected void onCreate(Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        try {
            initDB();
            startSync();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

The only thing left to do is to define some data in the database and show it to the users.

When to use Couchbase Mobile?

As always, you should find the best tool for the problem at hand. If your data is well structured and stable with no room for modification, then standard relational databases are the way to go.

If your data is flexible and should be available anytime and anywhere, this is by far the simplest solution.

The post Simple Server-Client Syncing for Mobile Apps Using Couchbase Mobile appeared first on Infinum.