Let’s face it. Carrying around a smartphone is like having a tracking device installed on your body. Those who have access to your device can know more about you and your habits than you know yourself.
Each of us has our own distinct set of features and habits. We have distinct faces, fingerprints, and voice patterns which identify us as unique. We like different things and visit different websites in distinct, predictable patterns. In a sense, our smartphones with their stored data, become microcosms of ourselves. Through use, they can become as unique as we are.
This uniqueness has been exploited in two-factor identification (TFA) security features that are now so common on many smartphones. We may have a password as well as a fingerprint or swipe to authenticate the fact that we, indeed, are the owner of the phone we are using. Other biometrics have been used for other security purposes. Unfortunately, since biometrics are ultimately based on software programs, they have been found to be vulnerable to hacking. (see my post, The End of Biometric Authentication?) Nonetheless, they are, in combination with passwords, able to offer better, if not perfect, security.
But what if you could add more security layers? What if you could combine biometrics, passwords, browsing habits, location, and other behavior patterns to identify a completely unique self as reflected in your smartphone ? Would you then be safe? Well, you’d be safer. If someone stole your phone, they would have a real difficult time convincing others that they were you.
Enter Google’s Trust API, an outgrowth of Project Abacus, which claims it will do away with all passwords for Android apps by the end of this year. If you need a password to use any Android app, Trust API will replace it by analyzing data stored on your device or by retrieving data from built-in sensors on the device to determine whether or not you are the device’s true owner. Data can be anything from facial recognition, to location, to your walking, typing, or browsing style. In the end, Trust API uses all of the data it can retrieve to determine a ‘trust score’. This is a probability metric which answers the question: “What are the chances this person is really the owner of this device?” A high trust score would allow you to use more sensitive apps, like banking apps, while a relatively low trust score would allow you do less risky tasks like playing games.
Since Trust API is continuously running in the background, it is continuously monitoring your behavior and biometrics (and probably shortening your battery life). If those monitored indices suddenly change, so will your trust level. At such times, you may be asked to verify your identity. If a person took your phone and happened to know or bypass your password, the lack of other information confirming the user’s identity would cause the trust level to fall to a point where all the apps would lock down. This could have a positive or negative effect.
I know many parents, for example, who allow their children to play games on their (the parents’) smartphones. Would Trust API detect that these children were not the real owners and lock them out? Can I ever lend someone my phone?
“When you upload, submit, store, send or receive content to or through our Services, you give Google (and those we work with) a worldwide license to use, host, store, reproduce, modify, create derivative works (such as those resulting from translations, adaptations or other changes we make so that your content works better with our Services), communicate, publish, publicly perform, publicly display and distribute such content.”
So, yes, if they want to use anything they gather from Trust API, they probably can and will.
Currently, Trust API is being tested by some banks. If those tests prove positive, the app would be ready for the general Android-using public shortly thereafter. That’s when we’ll really learn how well it performs. Users will, no doubt, find something to complain about. They always do. My experience in covering these matters tells me that the more software layers you try to use in security, the more problems you will have. Such solutions lack the simplicity and dependability of hardware separated security architectures.
High trust scores may be difficult to achieve if you do something out of the ordinary, like wear glasses, change your location or browsing habits, or have hurt your foot and are walking with a limp. It seems possible that your trust score may suddenly dive in the middle of a banking transaction. Then what? In other words, it may be that practical, rather than security, considerations could hamper widespread acceptance of the app.
However, possible security problems cannot be completely ignored. My guess is that hackers of all shades will be trying to be the first to hack Trust API and gain some instant notoriety. That’s just the way it is. Since almost all biometrics have been hacked in some way or another, it seems likely the system can be compromised or at least weakened. Just keep in mind that biometrics are simply biological indicators translated into code through software manipulation. It is a process that can be disrupted at any point in the translation process.
Trust API will probably pass the banking test but fail in its attempt to be widely accepted by users. The sad truth is that most users tend to choose ease of use over security. They simply don’t want anything that complicates their smartphone experience. Although we in the security business believe having the best security is essential, the average person just wants to use their device without anything, like good security, getting in their way. Changing trust levels along with messages asking them to verify their identity will be simply too frustrating for the normal user. As good as it may be, Trust API may see itself relegated to a minor role in the security landscape.