use of a background task was not further considered
and we backtracked to WP8.0.
Figure 2 refers to the communication scheme in
which this scenario was based. The main actors are:
Windows Phone, the pGina plugin working as BL
connection point, a database storing credentials
information and the ECG authentication accessed
using API. In 1, the WP app would send a message to
our server containing the username; in A, pGina
confirms the username with a database (2). A
feedback might be implemented, although we
considered at this point it would unnecessarily
increase the process complexity (3.1 and 5.1). Action
is suspended before 4, while waiting for Windows
logon; then, if ECG authentication is successful (5),
pGina allows logon and, possibly, returns feedback to
WP.
We also considered sending Bluetooth MAC
address from WP to pGina, in order to confirm the
identity of the phone itself – but WP will only allow
BL communication in-app with previously paired
devices, meaning no unpaired device could connect
with the server.
We chose to give the initiative of the
communication to WP and store all passwords in a
computer located database because: 1) the necessity of
asking for an explicit user interaction ruled out the
initiative being on server side; 2) in order to avoid
sending full credentials (user and password) through
Bluetooth we decided to store passwords on the server
side, and then identify the smartphone based on
username received and associated Bluetooth address,
both previously stored as well.
This solution worked by receiving a one-time
logon message from WP, which the server would
register with a timestamp and use in future logons
based on proximity. The process is the following: 1),
user is approaching the computer and sending the
logon message via Bluetooth. Then, the server
recognizes the phone as one authorized to logon in the
following hours (or any other predefined time range);
2) when no phone can be found nearby, logon is
denied; in 3) when the phone is again present, a logon
with the credentials associated to that user is allowed.
This means that, starting from 1), the computer itself
will search for the presence of the authorized phone;
the search will not require establishing a connection.
In fact, this search is different from the one stated
in the first scenario. Previously, we scanned for all
devices nearby and then verified the identity of each
one in search of a particular phone; with this new
approach, we tested the presence of a specific device
using a pre-stored address. In terms of time required,
a loop testing for a list of one phone changed logon
status in less than 2 seconds after turning off Bluetooth
in WP.
After implementing the Bluetooth side, we
approached the introduction of the ECG-reader
keyboard on the existing scheme. To better understand
the advantage of using a smartphone combined with
an ECG authentication, one must explain the latter.
This method works by first identifying a heart beat and
then authenticating the individual. Both processes can
take several seconds, thus leading to a delay in logon
process. Also, the authentication itself can be based on
different confidence levels. These two characteristics
bring a relevant improvement related to the use of a
smartphone as token – the computer is able to receive
the identification of the individual beforehand,
skipping the identification process and also being able
to use a better confidence level. The keyboard does its
own autonomous processing. It requires installing
VitalidiType (Technologies, 2015), the software that
allows interaction with the keyboard. The interaction
between the pGina plugin and this system is made
using its C# APIs, vitalidiAPI.
The ECG reader is the final step in our entire logon
scheme, taking advantage of the previously sent
information from the individual’s mobile phone.
In summary, the whole sequence is: 1), an
individual gets in the area covered by a Bluetooth
scanner in the computer; 2) this proximity triggers a
process of getting the ECG authentication username
associated with the detected mobile phone ready for
authentication; 3) a person attempts logon and the
keyboard uses the previously received username to
start authentication, reading the users’s heartbeat; 4)
the user is granted access if both authentications are
consistent with each other and succeeded.
3.2 Bluetooth Low Energy
As a solution to the GATT server role limitation in
Windows, we decided to implement a “middle point”
between the smartphone and Windows desktop. This
system was running Linux and, therefore, capable of
advertising a GATT service. In this scenario we also
changed from Windows Phone to Android to avoid
more limitations associated with their APIs.
The Linux system was capable of using BLE
through BlueZ, which provides support for this
technology. Also, in order to keep this a mobile, more
versatile and independent point, we used Intel Edison.
This board allowed us to create a GATT server,
listening for BLE messages from a smartphone, and
redirect them to our adapted pGina plugin running in
a Windows computer through Wi-Fi.