Like most of us, you probably have a pocketful of keys, FOBs, scan cards and a bunch of passwords and proprietary smartphone apps to gain access to your office, home, car, smart locks and even thermostats.
It would be ideal to know that every device maker implements effective security to avoid hacks and clones. But that’s not always the case. Instead, they typically invent their own proprietary authentication systems.
With each of these things providing you something unique to authenticate “you” to grant you access, you’re weighed down with passwords, FOBs, scan cards and more. Do we really need to design so many different ways to authenticate? The short answer, no.
FIDO: Single standards-based way to communicate who you are
A standards-based strong and secure authentication exists. It’s called FIDO. Working with Volansys and SurePass ID, a set of FIDO libraries help IoT embedded device makers add FIDO multi-factor authentication to their device via one of many FOB form factors or a smartphone app.
There are plenty of consumer advantages of widespread FIDO strong authentication use:
As a design engineer, if you use FIDO strong authentication for your smart devices, you’ll find
FIDO in action: Full working prototype
To illustrate a working FIDO strong authentication device, we asked Volansys to work with SurePass ID and Unikey to build a full working prototype of a FIDO-enabled smart lock built on top of a commercially shipping smart lock.
Volansys pulled together these elements of the prototype:
The core ideas driving FIDO are ease of use, privacy and security and standardization.
For implementing authentication beyond a password (and perhaps an OTP), companies have traditionally been faced with an entire stack of proprietary clients and protocols.
FIDO changes this by standardizing client and protocol layers. This gives rise to an ecosystem of client authentication methods such as biometrics, PINs and second–factors that can be used with a variety of online services in an interoperable manner.
Volansys has developed two applications running on the i.MX6 IoT Gateway. They are CGI handler and Proxy Server. Both these applications were developed in ‘c’ and run on Linux platform compiled for i.MX6.
The CGI Handler is responsible for handling all HTTP GET/POST request/response to access door lock. All requests are generated from FIDO client running on Android Application. It receives HTTP GET/POST request and sends the requested data to Proxy Server. Proxy Server is the only component that is responsible for sending commands to the kinetics bridge which in turn controls the lock associated with itself over the Bluetooth.
The Proxy Server is responsible for looking over FIDO authentication using FIDO server library. Whenever Proxy server receives data from CGI handler, it performs FIDO authentication. After successful FIDO authentication, Proxy Server sends lock control commands to Kinetis Bridge and receives the lock status response from the bridge. After receiving lock status, it notifies the Proximetry agent about the lock status and sends response back to android app through the CGI handler. Proxy server also handles the lock control commands from Proximetry agent. All the communications between android app, proxy server and Proximetry agent are in predefined format.
FIDO products and services erase the necessity of using passwords for security by adding FIDO U2F second-factor devices. Password usage can also be completely eliminated through FIDO UAF biometric solutions such as fingerprint or iris recognition sensors. If biometric data is used by a FIDO authenticator, the biometric information is securely stored in the device.
For more information for how you can leverage the FIDO libraries used in the prototype, please visit the IoT Center or let me know.
Bill Krakar is an IoT software product manager
Bill Krakar is a Software and Systems Product Manager for Internet of Things (IoT) solutions, with key responsibilities defining IoT solutions for Kinetis and i.MX processors. Bill has a Bachelor of Science in Electrical Engineering from University of Illinois. If Bill's not putting together an IoT solution, you'll find him exploring on a bike.
