See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/317580932

Two Factor Authentication

Technical Report · June 2017

DOI: 10.13140/RG.2.2.16228.99207

CITATIONS READS
0 4,599

1 author:

Jose Costa
University of Westminster
1 PUBLICATION   0 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Jose Costa on 14 June 2017.

The user has requested enhancement of the downloaded file.

 2FA2P2: A Two Factor Authentication Scheme
Jose Costa
Cyber Security Group,
Department of Computer Science
University of Westminster, UK
jose.costa@my.westminster.ac.uk
Abstract—While there are some available TFAs, most are either
privately made in house which other businesses cannot use or are
available but come with a lot of overhead which comes attached
to drawbacks; this can be expensive to implement and time-
consuming.
The aim of this project is to provide a secure TFA platform
to enable clients to provide their users with the form of security
without any change to their current infrastructure making the
transition effortless while keeping users data as secure as possible.
Keywords—Security, Two-Factor Authentication;
I. I NTRODUCTION
Two-factor authentication (TFA) is increasingly becoming a
go-to for user security and identification. With an increase in
cyber crimes each year more and more businesses (ranging
from financial institutions (HSBC, Barclays, BCA) to retail
(Amazon, eBay , Apple)) are implementing TFA as a way
to ensure user credibility within their systems which in turn
decreases the risk of any malicious users infiltrating into their
systems. TFA factors can be split into three categories as
written by John Brainard et al [1]
Knowledge Factors or Something you know Most com-
mon kind of authentication, examples range from passwords
to secret questions. Passwords are easily forgotten and can be
weak if not enforced properly.
Possessive Factors or Something you have Instead of hav-
ing to remember something possessive factors uses something
the user has, just like a key to a lock. These can vary from
smart cards which generate codes to USB tokens. Similarly to
Knowledge factors, possessive factors can be lost.
Inherence Factors or Something you are Inherence factors
use the users’ characteristics such as fingerprints, retinal scans,
dynamic signature as a matching pattern. These are harder to
spoof as they are unique to every person, however they are
harder to use and implement in older technology.
There are a multitude of ways that TFA, can work with
numerous of combinations available. The first normally being
a password, either created by the user or assigned to them upon
account creation, or a PIN (personal Identification Number).
Passwords will typically need to be remembered and this is
where security fails most often, users tend to create easily
memorable passwords and use the same password for several
of their accounts, when one becomes compromised attackers
can then perform malicious activities without the authorisation
of the account owner.
This is where TFA comes into play by adding an extra layer,
typically in the form of a physical token, such as biometrics
(fingerprints or retina scans), or electronic token such as a
One Time Password (OTP) generated at the time of the logon
request. If an attacker managed to get hold of the user’s
password, they would also need to get the user’s current OTP
to login which changes at a particular rate making it hard for
attackers to succeed in infiltrating an account.
A. Statement of Purpose
While there are some available TFAs, most are either
privately made in house which other businesses cannot use
or are available but come with a lot of overhead which comes
attached to drawbacks; this can be expensive to implement and
time-consuming.
The aim of our project will be to provide a secure TFA
platform which will enable our clients to provide their users
with the form of security without any change to their current
infrastructure making the transition effortless while keeping
users data as secure as possible.
As we are based within Europe we are obliged to meet the
established legislation for data protection set in the European
Directive 95/46/EC as well as the regulations set in the GDPR
(General Data Protection Regulation). According to [2], article
17 in the Directive, as the CSP (Credential Service Provider)
we must have, we will handle and store users information,
”appropriate technical and organisational measures to protect
personal data against accidental or unlawful destruction or
accidental loss, alteration, unauthorised disclosure or access”.
Authors in [3] also state that in article 17.1 that we must have
”a level of security appropriate to the risks represented by the
processing and the nature of the data to be protected”.
B. Aims and Objectives
For this project, we aim to make the application as
lightweight and simple as possible while keeping users data
protected. While our application is limited in its uses, we will
be focusing on the security aspect. As we are handling users
data, it’s our responsibility as devs to consider the legal issues
in addition to the moral obligations we have when storing and
moving data around which we’ll cover later on.
We aim to provide our services via API (Application
programming interface) requests which authorised businesses
will be able to call (once they implement the system they’ll be
given a unique API key which can be used to make requests to
our platform) whether it be to add a user to the TFA system or
check against an OTP provided by the user on a login attempt.
We plan to make an iOS app where the user will be able to
receive their dynamic OTP upon login. The OTP generated
will be a dynamic one where it changes every so often.
C. Stakeholders
Being a stakeholder fundamentally means that you’re some-
one which will be affected by or use the system. When
developing a system we need to know who’ll be using it so we
can tailor the system to them, are they technically able people,
how will they interact with the system once it’s implemented.
For our purposes our stakeholders would be external business
owners who would like to provide a TFA option for their users;
therefore their users also become part of our ecosystem. We
would provide the services for the owners while authenticating
their users. Stakeholders also include malicious users which
we will have to evaluate the ways in which they can attempt
to disrupt our services or impersonate other users and present
solutions as to combat the threat.
D. Organization
The rest of this paper is laid out in the following order.
In Section II we investigate and describe related work on
two factor authentication protocols and examples of existing
implementations. In Section III we walk through some of the
use cases for our project. Section IV describes both the system
and the adversarial model and strictly define the problem
statement. In V we present the cryptographic primitives used
throughout the paper. In VI we outline the functional require-
ments for our project. In VII we describe the protocols both
for the AP and the iOS app as formal constructions. In VIII
we describe the system setup and present relevant test results.
II. R ELATED W ORK
This section presents the most important works that have
been done within this area. In addition to that, we briefly
describe how each protocol works, and we present a list of
advantages and drawbacks. Finally, for each described related
work we provide a brief comparison with our approach in
order to highlight the differences and clearly present the
contribution of our work.
In [4] the authors propose a two-factor authenticator pro-
tocol which consists of a biometric formulation known as
BioHash. This combines a user specific fingerprint Bi with
a tokenised random number T which in turn produces a set
of n binary bit strings B = {b1 , . . . , bn }. This method makes
it hard for an adversary ADV to get hold of the required
authentication elements (B, T ) to even make the final product
needed for a successful authentication. Biometrics would not
be a viable option to use in your system due to the high
implementation cost both on our side and on the clients side,
also there are some drawbacks with the accuracy of such
systems as covered by the authors, false recognition rate (FRR)
and false acceptance rates (FAR) can be a problem within said
schemes and are not something which we are aiming to correct
or improve on.
To compile our requirements, we looked at already existing
forms of TFA and how they would compare to our proposed
system. We covered a variety of different approaches to TFA
and dismissed examples which would not be suitable for our
needs. An example of this would be using biometrics as TFA,
firstly the complexity of this task would take longer than the
allotted time given to complete this task. Another problem
would be that biometric scanning needs specialised equipment
which tends to be expensive, we would need to supply
businesses using our platform with such devices which takes
away from our aim of making it simple and easily integrable
into any business. We focused our search on mobile based
apps that had a form of two or multi-factor authentication
implemented.
Steams app is also available on both mobile OS;s, once you
have signed up to Steam Guard using your steam account, you
can then add your phone number which they use to send a
verification code to finalise the setup and identify the device
as yours. After that has been setup every time you access your
account the app will produce a code which changes regularly
as shown in 1.
Fig. 1: Steam Code
Duo is a company which focus on verifying the identity of
users for their customers as well as monitoring their devices
for performance. They incorporate agents which monitor and
enforce stronger policies by using TFA. They focus more on
remote login side and ensuring users only have access to
specific applications. This is a great tool to have in large
corporations that do not have have their own TFA system
that would also like to add some monitoring options to their
systems.
To show the differences between related products a feature
table has been created.
All of the compared systems are TFAs of their own, they are
all at industry standard, some being more focused on specific
areas than others- for example Duo must have an agent to get
 Use Case Number UC1
Use case 1
Description Business signs up to TFA, providing the required details
Actor(s) Business
Pre-Conditions User must not already be signed up
FLOW OF EVENTS

1) Business representative goes to TFA website and navigates to the business sign up page.
2) Rep enters required details and submits.

Alternative Flow
N/A
Exception If the business has already signed up or did not fill all
the required fields they will be alerted.
Post Conditions Business will now be registered and an API key will be
generated.
Fig. 2: Duo
TABLE II: Business signs up to TFA
Features HSBC Steam Duo TFA
Use Case Number UC3
Dynamic OTP Yes Yes Yes Yes Use case 3

Mobile Support Yes Yes Yes Yes Description Updating Details

Actor(s) Business User
Multiple Operating systems Yes Yes Yes No Pre-Conditions User must be signed up

Easy to use No Yes No Yes FLOW OF EVENTS

Easy to implement No No No Yes 1) Open app and navigate to according section

2) App loads Details section
Performance Focused Yes Yes No Yes 3) Enter data in required fields
4) App sends data back to server data is updated

TABLE I: Comparison Table Alternative Flow

N/A
Exception In step 3, if not all required fields are entered submission will not be
possible.
system health and performance reports. All of these generate
dynamic OTPs just like we have to implement in our system. TABLE IV: Account management for users on the app
They also all extend their services onto the mobile platform
just like we need to, above we can see their interface and Use Case Number UC4
Use case 4
we can take a lot in concerning user interaction with the app.
Description Deletion of accounts
The Steam app and Duo layouts seem more suitable for our Actor(s) User
needs as we need the app to be simple but serve its purpose of Pre-Conditions User must exist
providing the OTP to the user. Duo being the only one which FLOW OF EVENTS

can provide services to different businesses such as Sofware as 1) User opens app and navigates to correct section
a Service (SaaS) cloud-based services [5] has the drawback of 2)
3)
App loads correct section and prompts user with conditions
User must accept conditions
the extra baggage of needing an agent to be introduced into the 4) App makes request and users records are removed from the system.

client system, while what we need is something simple that can Alternative Flow
easily be implemented. For our TFA platform we must keep it N/A
as simple as we can so businesses do not have to change their Exception User must accept conditions on deletion.

infrastructure to use our services.

III. U SE C ASES
This chapter describes some of the use cases and how we
handle certain situations. We also provide alternative routes
that could be taken depending on the same events happening
in different conditions.
IV. S YSTEM M ODEL AND P ROBLEM S TATEMENT
In this section, we will be discussing the system model.
More precisely, we will walk through each element of the
system with a brief overview for each.
A. System Model
In this part of the paper, we identify all the participating
parties in our system model and briefly explain their
operations and how they relate to each other as well as the
TABLE V: Account management and deletion for users
adversaries we’re up against and the security requirements
needed to deal with them.
Our system consists of three participating entities: our
Users, Webservices and the 2FA APP.
a) User (u): Let U = {u1 , . . . , un } be the set of all users
that are registered with our service. Users within the system
can use the 2FA2 p2 to login to the available webservices (WS)
using the provided OTP from the app regardless if the user is
registered to that specific webservice or not. Webservices can
directly communicate with the 2FAApp by using a unique API
Key acquired when the WS registers to use the service. This
will be used to validate by authenticating requests made to the
 Use Case Number UC5
Use case 5
c) Two Factor Authentication Service (2FA2 p2 ): 2FA2 p2
Description Request of OTP can communicate both with the users and webservices. 2FA2 p2
Actor(s) User provides issues codes for users to login onto registered web-
Pre-Conditions Must be a member of a business that has incorporated TFA. services. 2FA2 p2 also generates and assigns API Keys when
FLOW OF EVENTS
webservices register to the platform, these will be used to
1) User must login with right credentials on supporting businesses site.
2) Business backend will then make an API call to the TFA platform.
validate and authenticate the webservices’ request.
3) App will produce an OTP that the user can then use to finalise the login process.
B. Adversarial Model
Alternative Flow
Our adversarial model is based on [6], the Dolev-Yao ad-
1) User opens app
2) App requests data from TFA platform and produces OTP
versarial model. In this threat model, the ADV can intercept,
3) OTP displayed and user can then use it to login to business site. overhear and change messages which are sent and received by
Exception N/A
our systems. We also assume that the ADV can be a legitimate
user in the system.
TABLE VI: OTP Request Cryptographic Security: We assume encryption schemes
are secure such that the ADV cannot access the original
Use Case Number UC6 plaintext message. We also take into consideration that the
Use case Generate OTP signature scheme is unforgeable such that ADV cannot forge a
Description On requiring an OTP users can initiate the app and obtain an OTP valid signature and that signature verification algorithms work
Actor(s) Business User
Pre-Conditions User must be part of the system
correctly. We also assume that the ADV cannot predict the
FLOW OF EVENTS output of a pseudorandom function. We take into consideration
that the ADV can compromise data and change the message
1) Users initiates the app
2) App requests data from TFA server on login during transit. We assume the ADV can perform a variety of
3) App then calculates OTP with requested data and displays it.
attacks such as brute force, rainbow attacks and MITM attacks.
Alternative Flow Asset Security: We assume the ADV cannot deny access
N/A to a valid user, such as making a web server unavailable. We
Exception N/A
also assume the ADV cannot gain access to the database but
TABLE VII: OTP Generation on the mobile device when can try SQL injection attacks to gain access to undisclosed
prompted by the login process data from the database server.
V. C RYPTOGRAPHIC P RIMITIVES
Use Case Number UC7
Use case Generate OTP (TFA platform)
We will use the following notations for cryptographic op-
Description Upon needing to validate a OTP entered by the user, the server erations throughout the paper. The set of all binary strings is
recalculates and compares. denoted as {0, 1∗ } and the set of all binary strings of length
Actor(s) Business n h

Pre-Conditions User/Business must be apart of the system

FLOW OF EVENTS
1) Server receives request to validate OTP from a specific user.
2) Server calculates an OTP for the user and compares with the password sent in.
Alternative Flow
N/A
Exception N/A
TABLE VIII: Once the webservice has aquired the OTP from
the user, it then makes a request providing the OTP which the
TFA platform then validates and sends a response.
2FAApp.
b) Webservice (ws): Let WS = {ws1 , . . . , wsm } be
the set of all webservices that 2FA2 p2 provides service to.
Each wsi ∈ WS has a public/private key pair denoted as
pkwsi /skwsi . The public key is shared with all other entities
in the system model while the private key is kept private.
A wsi communicates directly with the 2FAApp to verify
users credentials to which 2FAApp can respond with a user
validation (so a login response) or a registration response if
the user does not already belong to said WS system.
n as {0, 1} . Given a set of U , we refer to the it as ui .
Additionally, we use the following notations for cryptographic
operations throughout the paper:
Definition 1 (Private-Key Encryption Scheme): A private-
key encryption scheme is defined by three algorithms. The
key generation algorithm Gen, the encryption algorithm Enc
and the decryption algorithm Dec such that:
1. Gen is a probabilistic algorithm that outputs a crypto-
graphic key K based on a security parameter l and a
distribution. The finite set of all possible keys that Gen
can output is called the key space and is denoted by K. In
addition to that, there is a specification of message space
M such that |M > 1|.
2. Enc takes as input a key K ∈ K and a message
m ∈ M and outputs a ciphertext cm . The encryption
algorithm may be probabilistic and we denote this by
cm ← Enc (K, m). We let C denote the set of all possible
ciphertexts that can be output by Enc(K, m) for each
K ∈ K and m ∈ M.
3. Dec is a deterministic algorithm that takes as in-
put a key k ∈ K and a ciphertext c ∈ C and
outputs a message m ∈ M. We denote this as
m := Dec(K, cm ) = DecK (Enc(K, m)).
 Definition 2 (Public-Key Encryption Scheme): A public-
key encryption scheme is a tuple of three probabilistic
polynomial time algorithms (Gen, Enc, Dec) such that:
1. Gen is a probabilistic algorithm that takes as input a
security parameter l and outputs a public/private key pair
pk/sk.
2. Enc is a probabilistic algorithm that takes as input a
public key pk and a message m and outputs a ciphertext
cm . We denote this by cm ← Encpk (m).
3. Dec is a deterministic algorithm that takes as input a pri-
vate key sk and a ciphertext c and outputs a message m.
We denote this as m := Decsk (cm ) = Decsk (Encpk (m)).
Definition 3 (Symmetric-Key Encryption Scheme): A
symmetric-key encryption scheme consists of three
probabilistic polynomial-time algorithms (Gen, Enc, Dec)
such that:
1. Gen is a probabilistic algorithm that takes as input
a
security parameter l and outputs a key K ← Gen 1l )
such that K ∈ K and the key length |K ≥ l| .
2. Enc is a probabilistic algorithm that takes as input a key
K and a message m and outputs a ciphertext cm . We
denote this by cm ← Enck (m).
3. Dec is a deterministic algorithm that takes as input a
keyK and a ciphertext c ∈ C and outputs a message m.
We denote this as m := Deck (cm ) = Deck (Enck (m)).
Definition 4 (Message Authentication Code (MAC) ): A
Message Authentication Code (MAC) [7] consists of three
probabilistic polynomial-time algorithms (Gen, Sign, Vrfy)
such that:
1. Gen is a probabilistic algorithm that takes as input
a
security parameter l and outputs a key K ← Gen 1l )
such that K ∈ K and the key length |K ≥ l| .
2. Sign is a probabilistic algorithm that takes as input a key
K and a message m and outputs a tag T ← Signk (m).
3. Vrfy is a probabilistic algorithm that takes as input a
key K, ciphertext m ∈ M and a tag T and verifies
the authenticity of T such that the ouput bit b :=
Vrfyk (m, T ) = Vrfyk (m, Signk (m)) where b = 0||1 if
the signature is valid or not.
Definition 5 (Non-keyed Hash): A hash function H takes
m as the input and produces an output known as a hash −
value or hash denoted by h = H(m). Hashes serve as a
digitalf ingerprint also called a messagedigest and can be
used to uniquely identify a messages integrity. Once m and h
is sent to the recipient we can hash m and compare with h.
Definition 6 (Salt and CSPRNGs): A salt is denoted as S =
RAND(n) where n is the number of bits using a cryptograph-
ically secure pseudorandom number generator (CSPRNG) op-
posed to a pseudorandom number generator (PRNG). PRNGs
produce numbers which look random but are in fact created
by a deterministic algorithm which makes the random values
reproducible making them insecure to use.
Definition 7 (Key Derived Function): KDFs are determin-
istic algorithms which are used to derive cryptographic keys
,k, from a secret value. Password Based KDFs (PBKDF)
include input of a password denoted as P , a salt, S, an
iteration count , C, the length of the desired key kLen and
the Pseudorandom Function P RF to use. We denote k as: k
= PBKDF(P, S, C, kLen, P RF )
VI. R EQUIREMENTS
Using our research in our previous requirements report we
can address some of the issues and provide some function and
non functional requirements.
A. Functional Requirements
Requirement Level
R1. Businesses must be able to register their users with our services. MUST
Description For our services to run a business must first sign up and
retrieve an API key to implement our system.
R2. The generation of the OTP must be efficient. MUST
DescriptionMaking the generation process of the OTP efficient should
be one of our top concerns, if our system generates the codes ineffi-
ciently users will have to wait for them which will drive businesses
elsewhere.
R3. Users must be able to receive the OTP via the app. MUST
DescriptionAs we have gathered via our research users would rather
have an app to an extra physical device, for this we must have an app
which displays the generated OTP.
R4. OTP’s must be generated only for legitimate/authenticated users. MUST
Description We must check the legitimacy of the user requesting an
OTP before sending any data for increased security.
Requirement Level
R5. Businesses should be able to manage their account SHOULD
DescriptionBusinesses may have the ability to manage their subscrip-
tion to our services and update any of their details.
R6. Users should be able to manage their account. SHOULD
Description Users should be able to modify details or delete their
account if required.
R7. Malicious requests for the generation of OTP’s that could lead to SHOULD
a Denial of Service attack [8], [9], [10], [11] should be identified and
the corresponding IP addresses should be blocked.
Description Looking at login patterns and general area of access is
a way in which this could be achieved, if the request does not fit
the pattern we could temporarily block access and have the business
request an unblock when verified.
R8. Users should be able to register via various businesses. SHOULD
DescriptionUsers working for different businesses that are using our
platform should have different OTPs for both every business they
belong to.
B. Non-Functional Requirements
VII. P ROTOCOL D ESCRIPTION
In this section, we will describe the main protocols. These
protocols are successively applied to deploy a two-factor
authentication infrastructure providing web-services user au-
thentication as well as data integrity and security. We cover
the 2FA architecture and what programming languages were
used.
We present our construction for 2FA2 p2 with our 3 partici-
pating entities: a webservice (W S), a user and an authentica-
tion platform (AP ).
 Requirement
NF1. Sending and receiving of data between CSP and business must
be encrypted at all times
DescriptionTo combat packet sniffing/snoopers and keep data secure
we must not send plain messages and we have to comply with laws
stated in [2].
NF2. Data transactions between CSP and user must be encrypted at
all times
Description To combat packet sniffing/snoopers and keep data secure
we must not send plain messages and we have to comply with laws
stated in [2] section.
NF3. An OTP must be generated in a truly random way
Description This is a must as if the algorithm is simple and data is
intercepted codes could easily be generated.
NF4. The same OTP must not be generated more than once
Description
NF5. Freshness of the OTP must be verified from the authentication
server
DescriptionAuthentication server will use time based systems when
verifying OTPs validity.
Requirement
NF6. Each OTP must be secretly bound to a specific user identity
DescriptionEach OTP must be unique to each individual user every
time a user makes a request.
NF7. Data integrity must be insured
DescriptionAs we are keeping user data we must ensure that any
unauthorised data tampering is avoided at all times
NF8. Data logs must be kept
DescriptionTo keep track of user requests and data access we should
keep logs to reference, this will make it significantly easier to identity
problems with our system and spot malicious activity.
NF9. API call rate limiting
DescriptionTo ensure we do not get attacked via DoS we can put
a limit on how many requests we can take over a certain period of
time to make sure the servers do not get overload and completely stop
functioning.
a) Key Setup: W S and AP both obtain a public/private
key pair. The public key of each entity is shared with everyone
while the private remains secret. Below we provide the list of
the key pairs used in by the entities that are participating in
our protocol:
• pkWSi /skWSi - public/private key pair for W Si
• pkAP /skAP - public/private key pair for AP
b) Registration: For a W S to gain access to our platform
they must first sign up providing details about their webser-
vice. Upon completion, they will be assigned a unique AP I
key which solely identifies the specific W S. This key will be
used to authenticate requests made by the W S when they wish
to validate user access.
In addition to W S, each user ui must also register to
our platform 1 . When ui sends a registration request, AP is
responsible to verify the validity of the request (e.g. user ui is
not already registered). If the request is legitimate, then AP
initiates the registration process.
When ui registers they are required to provide personal
details along with a username and password combination. ui
proceeds by constructing the message, m1 , to be sent:
m1 = {username kH(password) kdetails }
1 Note that registration process of user is different from the registration of
a W S.
Level
and then encrypting it with AP s public key pkAP to get c1 ,
MUST
where c1 is the encrypted message:
c1 = EncpkAP ({username kH(password) kdetails })
MUST
Upon reception, AP uses skAP to decrypt c1 and recover
m1 = DecskAP (c1 ). Next AP checks if said ui is part of
their system already, if not it saves their details into a secure
database while storing registration time by executing the cur-
MUST rent time function to get τ . AP also generates a salt, si ,using
a cryptographically secure pseudorandom number generator
(CSPRNG) which is unique to ui . The salt will also be stored
MUST
to be concatenated to the end of the hashed password to be
MUST hashed and stored.
Passwords on server are determined and stored as such:
SPui p = H(H(password) + si ).
Level AP also generates another random binary sequence of
MUST length n, where the resultant sequence becomes a unique key
(uki ) for ui which will later be used to calculate the OT P .
MUST UserTable : {username kSPui p ksi kτ kuki }
c) Requests: User ui wishes to login to W Si using
2FAAPP. u1 provides their username and password so that
SHOULD
W si can make an account verification request to the AP
by constructing a message m1 such that m1 = {username
kH(password) kW SiAP Ikey }. W Si then encrypts m1 with
SHOULD
AP s public key pkAP to get c1 = EncpkAP (m1 ).
Upon receiving c1 , AP then decrypts the ciphertext using
skAP to get m1 := DecskAP (c1 ) and follows up with an API
key validation of W SiAP Ikey . Providing the key is valid and
the user exists AP proceeds to find the username supplied
in its users table and calculates the salted hash of the hashed
password provided in m1 , H(H(password) + si ), comparing
it to the stored hash. Once the users credentials have been
certified AP sends back a signed response to W Si , c2 =
{(σskAP (m2 )k(m2 )}. W Si checks the digital signature σskA P
and if the resulting check returns true (sender verified), W Si
prompts ui for an OT P .
d) OTP Generation: When ui is requested for an OT P
they open their app and an OT P will be displayed for a given
amount of time.
OT P generation algorithm:
Take τ , uki and si for ui (locally stored)
current time = CT , OT P gen rate = α
η = δ( CT - τ ) / α
C = base iterations
OT P = PBKDF(uki ksi k(C + η)kP RF )
By hashing uki η times we can always ensure that the OT P
is always different as η will always change every α seconds.
Our algorithm will give us a hexadecimal string which we’ll
take a substring of which will be our OT P .
e) OTP verification: In the verification step we first
determine the signature of the decrypted ciphertext, c3 , and
AP repeats the OT P generation algorithm above since the
required data is also stored.
During the last phase of the protocol, ui provides W Si
their current OT P which then W Si makes an API request
to the AP by constructing message m3 consisting of W Si
API Key, OT P , ui username such that m3 = { (user-
name kOT P kW SiAP Ikey ) } and then signing with W Sisk
and encrypting with APpk such that the ciphertext c3 =
EncAPpk (σ W Sisk (m3 )km3 ).
VIII. I MPLEMENTATION
We now describe the implementation and setup of our
system and which technologies were chosen to fully meet
our needs and requirements. We’ll discuss the languages and
frameworks that we used and how they were used throughout
the project.
Our platform is deployed on a resizable Virtual Private
Server (VPS) or Cloud Server on Digital Ocean [12] called
a droplet. The droplets current specs for the VM hosted on
Digital Ocean:
————————————————————————
———————————————————— 512 MB
Memory / 20 GB Disk / LON1 - Debian 8.7 x64 kernel
version 3.16.0-4-amd64
—————————————————————————
———————————————————
Hosting the VPM on Digital Ocean allows us to scale
effortlessly, both vertically and horizontally, depending on the
traffic to our server. They offer block storage which allows us
to increase the storage size of our system easily without taking
it down. We can also improve the system specs by selecting
a different package plan, for our purposes the lowest of the
package plans was sufficient.
A. Server-side Setup
We run our authentication platform on a Node JS server,
Node JS is an environment which allows JavaScript to be run
outside a Web Browser. Due to the lack of object oriented
nature of JavaScript we decided to use Typescript. Typescript
is a superset of JavaScript developed my Microsfot which adds
class based objected oriented programming into JavacScript.
B. Setup
1) Back-End: For our server, we needed something which
had asynchronous and non blocking capabilities which would
allow us to upscale or downscale depending on the user base.
Node JS framework matched our criteria on every front; it
also makes it possible to deploy new instances effortlessly in
the event that our user base grows to the point where our
current system model cannot handle the volume of requests.
In [13], Tilkov et al cover the main aspects of using the Node
framework for a high-performance server.
Since our VPS has been hosted on Digital Ocean we can
aim to have 99.99% uptime as stated in DOs service-level
agreement (SLA) [14], with this in mind we must make sure
that our Node server has minimal downtime to not disrupt the
usual service. To do this, we introduced a production process
manager, PM2. Its job is to keep our server alive and restart
it if the server goes down, this may be due to an error that
got through the production stage, or Digital Ocean has a lapse
in service in which case on restart PM2 will start the Node
server again as soon as the VM has relaunched.
Following Kerckhoffs principle [15], where a crytosystem
should be secure if everything about such system but the pri-
vate key were to be public knowledge including the algorithms
used, we have to provide security to our system as to not allow
any foreign users access to our VM.
We took several steps to try and achieve this, we first created
a user in our machine and added it to do the SUDOers group,
this allows us to disable root login onto the machine which
is typically what ADV will try to attempt first. We then
proceeded by setting up a firewall to block any connections
made to the server on any unauthorised ports. We kept SSH
connections open for server maintenance but only accessible
by our recently made sudo user. On top of everything else,
we introduced NGINX [16] onto the stack. NGINX is used as
a reverse proxy to redirect HTTP connections to our HTTPS
enabled Node server (HTTP on 80, forward to our declared
Node ports which have SSL enabled).
NGINX also serves as a load-balancer for our services. It
allows us to have multiple Node servers running on various
secure ports and we can configure NGINX to round-robin
requests on the various Node servers.
We can further fine tune this by providing server weights
to the load balancing algorithm in case the hypervisor hosting
one of our VMs is running on better hardware allowing us
more computing power on a particular Node server. NGINX
can also perform health checks on servers, if one of the servers
is operating under par, it will lower its priority to give jobs to.
C. Languages
1) Typescript: TypeScript [17] is a free open source lan-
guage that has been developed by Microsoft to add static type
checking and class based objected oriented programming
(OOP), it compiles into basic JavaScript. This is a great
language to work with in large projects where we need
structure mechanisms in place; TS allows us to do that while
also enabling us to use all the JavaScript tools. TS is a
great development language as it comes with error detection
before compilation which is helpful during the implementation
process.
2) Pug: Pug [18] formerly known as Jade, is a templating
language which allows us to generate HTML from JavaScript.
We use this so that our Node server (using Express) can deliver
data onto the page effectively. Below is an example of how
this works.
1 r e s . r e n d e r ( ’ i n d e x ’ , { t i t l e : ’ Pug Demo ’ , m e s s a g e : ’
T e s t Data ! ’ } ) ;
2
1 doctype html
2 h t m l ( l a n g = ’ en ’ )
3 head
4 meta ( c h a r s e t = ’ u t f −8 ’)
5 title title
6 body
7 h1 m e s s a g e
 User Web Service 2FA Platform

Login.Request
* +
c1 = EncpkAP ({username kH(password)})

Verify

Response

Gen.OTP
* +
OT P = PBKDF(uki ksi k(C + η)kP RF )

username,OT P

Gen.OTP
* +
c2 = Enc(APpk {username kOT P kW SiAP Ikey }kσ W Sisk )

Verify

Response
Grant or deny access

Fig. 3: Sequence Diagram of Login Request and OT P Generation Verification

8 . 3) Swift: Swift [19] is a general purpose open source

Listing 1: Pug Template language designed by Apple released in 2014. This language
was created inhouse and it provides a wide plethora of
improvements from the legacy iOS programming language,
Objective C. Swift was picked over Objective C due to the
fact Swift is faster overall. It has less overhead and it lets us
do more with less with it’s strong typing and simple syntax.
D. DBMS
1 <! d o c t y p e html> 1) Redis: During the start of our implementation process
2 <h t m l l a n g = ’ en ’> we used Redis [20] as a temporary solution for our DBMS.
3 <head>
4 <meta c h a r s e t = ’ u t f −8’> Redis is a fast in-memory noSQL database which together
5 < t i t l e >Pug Demo</ t i t l e > with Node allows for quick integration and data storage. Redis
6 </ head> could also be used as a way to store current session data,
7 <body>
8 <h1>T e s t D a t a ! </ h1> temporary data which will be accsssed multiple times over
9 </body> the session, to decrease querying time.
10 </ html> 2) PostgreSQL: In our final implementation we switched
Listing 2: HTML output over from Redis to PostgreSQL [21] as we need a relational
database (RDBMS) to store our relational data. PostgresQL
 setup time is a little longer comparing to Redis and not as fast
but it has the ability of vertical scaling, no limit on record
numbers, which would be needed for our client base.
1 v a r q u e r y S t r i n g = ”INSERT INTO U s e r s ( f i r s t n a m e ,
l a s t n a m e ) VALUES ( ”D” , ”McCoy ” ) ;
Listing 3: Typical SQL insert query with PostgreSQL
3) Other worthy mentions: MongoDB [22], first released in
2009, is a noSQL database which uses JSON-like documents
for storage. This DBMS can scale horizontally by sharding
(creating new partitions which are held separate to each other),
this can increase latency when querying due to multiple
shards having to be queried. MongoDB was a tempting choice
at first due to its meshing capabilities with Node however a
RDBMS was the better option for our needs.
1 v a r c o l l e c t i o n = db . c o l l e c t i o n ( ” t a b l e N a m e ” ) ;
2 / / I n s e r t a s i n g l e document
3 c o l l e c t i o n . i n s e r t ( { key : ’ i t e m ’ } ) ;
4) Libraries,Frameworks and Packages: Since we are using
Node, we have access to NPM. This is the packet manager for
JavaScript and it’s the self proclaimed world’s largest software
registry.
Through NPM we have numerous tools at our disposal
to make the implementation as smooth as possible. We can
install and easily introduce packages and add them to our
dependencies list all with NPM.
1 # I n s t a l l t h e p a c k a g e and s a v e i t i n o u r d e p e n d e n c i e s
2 $ npm i n s t a l l e x p r e s s −−s a v e
Listing 4: Installing a package with npm
Express [23] is a minimal Node web framework that
provides a robust set of features to facilitate the development
of web applications. It enables rapid development of Node
based applications. For our purposes we mainly take advantage
of its routing capabilities and create all our servers endpoints.
Below is an example route, when accessing the ”/” route,
www.example.com/, the server responds by rendering the
index page.
1 app . g e t ( ” / ” , f u n c t i o n ( r e q , r e s ) {
2 r e s . r e n d e r ( ’ index ’ , r e s ) ;
3 }) ;
Asynchronous JavaScript uses callbacks to return data after
execution of async functions have finished. This is a widely
known nightmare for most JS developers as it can get difficult
to stay on top of callbacks due to the nesting nature of them.
To make things easier promises were made. In our project we
use Bluebird promises [24], they provide us with a cleaner and
more robust way of handling async code and error handling.
This is much needed as all of the database queries are async
functions.
PostgreSQL does not support promises but npm can provide
us another library, pg-promise [25], which translates their
callback interface into responses based on promises. This facil-
itates data transactions and connections and also provides great
query chaining ability and error handling. pg-promise also
escapes SQL queries before executing queries, this eliminates
that security weakness by preventing SQL injections.
a) : Another library used as mentioned previously is
a template engine, PUG, used to interpolate variables into
the HTML without concatenating them in directly ourselves.
We use Helmet [26] to aid with with HTTP header security
in Express.js. Helmet is a collection of smaller middleware
functions that set HTTP headers. One way in which an
ADV can try to attack our system is by investigating which
technologies we’re using and using known exploits to penetrate
our systems. Helmet provides ways to combat some of theses
attacks. An example of this would be the X-Powered-By
header, this gives information on which technology powers
the server. By default this tells the client we’re using Express,
the ADV could use this to find a known vulnerability with
Express or Node upon seeing this header. Examples of other
attack preventions include cross-site scripting (XSS), which is
when an ADV can place malicious JavaScript onto our page.
Helmet solves this by allowing us to set the Content-Security-
Policy (CSP) header, we define a whitelist of sites where the
browser should load things from such as CSS.
b) : Another module used is Crypto [27], this module is
the most important one security wise. Crypto provides us the
cryptographic functions that include signing and verification
of messages, general hashing and PBKDF functions.
Below are some snippets of the implementation of cryptos
functions:
1 c r y p t o . p b k d f 2 S y n c ( p a s s w o r d , s a l t , i t , kLength , t h i s .
hashAlgo ) . t o S t r i n g ( ’ base64 ’ ) ;
Fig. 4: Generating an OTP using PBKDF snippet
1 l e t e n c r y p e d D a t a = c r y p t o . p u b l i c E n c r y p t ( c e r t , new
B u f f e r ( d a t a ) ) . t o S t r i n g ( ’ base64 ’ ) ;
2 l e t s i g n = c r y p t o . c r e a t e S i g n ( ’ sha256 ’ ) ;
3 sign . update ( ’ encryptedData ’ ) ;
4 l e t s i g n a t u r e = s i g n . s i g n ( privateKey , ’ base64 ’ ) ;
Fig. 5: Encrypting data with the public key derived from the
certificate and signing with the private key
1 l e t e n c r y p t e d D a t a : s t r i n g = r e q . body ;
2 l e t b u f f e r = new B u f f e r ( e n c r y p t e d D a t a , ’ b a s e 6 4 ’ )
;
3 l e t decryped = crypto . privateDecrypt ( privateKey ,
buffer ) ;
Fig. 6: Decrypting Snippet
To generate our API-keys we used the node–uuid li-
brary [28], this library generates universally unique indentifiers
(UUID). node-uuid follows the the UUID standards published
by the Internet Engineering Task Force (IETF),RFC 4122 [29],
and can generate 2 of the 4 versions of UUIDs. Version one
being time based generation and version 4 being randomly
generated using cryptos CSPRNG. For our purpose we use
the the latter of the two that returns the string form of the
uuid which we assign the a specific webservice.
KeyChain Services [30] was used in our mobile app to
provide the means to keep sensitive information such as pass-
words certificates and the sort safe. Data is stored locally and
can be restricted access by setting passwords and specifying
who has access to the data.
Another library used in our app was Alamofire [31], a HTTP
networking library. It facilitates the process of sending requests
to our platform with the right data and has the ability to parse
the response accordingly. It allows for chain requests to be
made as well as the ability to download responses to files
which helps with logging if necessary.
E. Keys, Certificates, Certificate Authorities and Safety fea-
tures
For our platform to incorporate our desired security stan-
dards relaying hashed data via an unsecured channel was not
enough. This could easily be intercepted by an ADV and
changed via a man-in-the-middle-attack (MITM) which could
change the data without the recipient ever being aware.
At the beginning stages of development we produced our
own self-signed certificate via OpenSSL [32]. This provides
the means to create our own private key and certificate signing
request which is required to create an SSL certificate. With our
certificate being self-signed it still provided the protection a
Certificate Authority (CA), the entity that is responsible for
issuing certificates, signed certificate would provide but users
would have to add our certificate to their exception list which
would would turn them away. To solve this we turned to Let’s
Encrypt [33]. Let’s Encrypt is a non profit automated CA
whose aim is to promote the adoption of HTTPS for a more
secure and privacy-respecting Web. They provide the means to
obtain, renew and manage SSL/TLS certificates. Technology to
encrypt web communication has been around for a long time
but it’s been a challenge to use even for technical people,
Let’s Encrypt allows us to acquire, install and manage our
certificates at no cost.
After successfully setting up our certificate and our 2048-
bit RSA keys we ran tests on SSL Labs and HTBridge [34]
which provide the means to perform deep analysis on config-
uration of a web server by check NIST guidelines [35], PCI
DSS compiances [36], HIPPA guidance [37] as well as the
industry’s best practices and assigns it a rating.
IX. C ONCLUSION
In this paper, we proposed a protocol for secure and efficient
sharing of ehealth data in a multi-cloud environment. The
proposed protocol was based on a Revocable Key-Policy
Attribute-Encryption and allowed users to control access rights
directly on encrypted data. Moreover, the proposed protocol
allows secure and efficient revocation of access to data, for a
certain user that is compromised, misbehaving or is no longer
part of a user group, without having to decrypt and re-encrypt
the original data.
From a data transmission point of view the proposed model
has met most of the guidelines proposed by NIST, such
as interoperability or ability to function with already exists
systems by implementing and using and adhering to standard
communications protocols as well as using the common base
and approved cryptographic algorithms and key lengths. We
try to assure data integrity by signing before data is sent and
then computing the resultant check when the data is received.
This provides a measure of assurance of data integrity as
stated in the NIST guidelines. Using RSA certificates keeps
messages under wraps between end points and it’s currently
impossible to break, calculated to take a system with the
standard computing power of a desktop 4,294,967,296 x 1.5
million years to break the certificate.
We try to keep password entropy high by enforcing case
sensitive alpha numeric with at least 14 character length l
which is in the 99th percentile of password length disctribtion
according to Bruce schiener [38], this equates to a total of
62 symbols (N ) where the key space K ← N l , which is
1.25 ∗ 1025 and has 57.6 bits of entropy. We think this is a
good length as any longer and users will start to write their
passwords down which causes another problem entirely.
To prevent a variety of attacks, we implement failed attempt
lock-outs to prevent brute forcing; and salting and hashing of
the passwords which automatically negates dictionary attacks
and rainbow table attacks. By also using derived keys (using
PBKDF2) we increase the computational time needed to
calculate the passwords also known as key stretching, this
can vastly increase the time required for an ADV to try and
compute the password. With CPU power being left trailing
by new GPU technology, ADV are now switching over to
GPU systems to try and get into systems. The most powerful
GPU system being a rig which consists of 8x Nvidia GTX
1080 hashing dedicated machine [39] running Hashcat [40]
and can produce staggering numbers of hashes, over 1000
kH/s (thousand hashes per second) PBKDF2-HMAC-SHA256
hashes, which totals to 9473.2 kH/s. Although our system will
probably never face an ADV like the one mentioned, lock-
outs are a must to prevent online attacks. We’ve covered only
a small sample of attacks in our project but have learnt a
massive amount from taking this task on.
The product has met it’s goal of being lightweight and
easy to integrate into interested businesses of any kind by
having little to no work needed to implement into other
webservices and just having the user download an app on their
phone. Further steps to take in the future development in this
project would be to implement a white list of ips which our
platform can trust and also a database for known malicious
users or ips. Also develop a wider distribution of platforms
that can run our app. With a little more work this system
can definitely be implemented into real life environments to
essentially strengthen their security.
In addition to that, we plan to implement our protocol in
a cloud environment [41], [42], [43], [44], [45], [46], [47]
and measure its performance. Furthermore, we plan to explore
the incorporation of our protocol with mobile sensing ap-
plications and with privacy-preserving reputation systems for
cloud-based participatory sensing applications. The envisioned
system will be based on [48], [49], [50] and will effectively
maintain the privacy and anonymity of users [51], [52]. Finally,
we plan to explore the possibility of use such an authentication
technique in e-Health applications [53], [54], [55] where users’
data are considered sacrosanct [56], [57].
R EFERENCES
[1] J. Brainard, A. Juels, R. L. Rivest, M. Szydlo, and M. Yung, “Fourth-
factor authentication: somebody you know,” in Proceedings of the 13th
ACM conference on Computer and communications security, pp. 168–
178, ACM, 2006.
[2] E. Kennedy and C. Millard, “Data security and multi-factor authentica-
tion: Analysis of requirements under eu law and in selected eu member
states,” Computer Law & Security Review, vol. 32, no. 1, pp. 91–110,
2016.
[3] J. Camenisch, S. Fischer-Hübner, and K. Rannenberg, Privacy and
identity management for life. Springer Science & Business Media, 2011.
[4] A. T. B. Jin, D. N. C. Ling, and A. Goh, “Biohashing: two factor
authentication featuring fingerprint data and tokenised random number,”
Pattern recognition, vol. 37, no. 11, pp. 2245–2255, 2004.
[5] A. Michalas and M. Bakopoulos, “Secgod google docs: Now i feel
safer!,” in 2012 International Conference for Internet Technology And
Secured Transactions, pp. 589–595, Dec 2012.
[6] D. Dolev and A. Yao, “On the security of public key protocols,” IEEE
Transactions on information theory, vol. 29, no. 2, pp. 198–208, 1983.
[7] H. Krawczyk, R. Canetti, and M. Bellare, “Hmac: Keyed-hashing for
message authentication,” 1997.
[8] A. Michalas, N. Komninos, N. R. Prasad, and V. A. Oleshchuk, “New
client puzzle approach for dos resistance in ad hoc networks,” in
Information Theory and Information Security (ICITIS), 2010 IEEE
International Conference, pp. 568–573, IEEE, 2010.
[9] A. Michalas, N. Komninos, and N. R. Prasad, “Mitigate dos and ddos
attack in mobile ad hoc networks,” International Journal of Digital
Crime and Forensics (IJDCF), vol. 3, no. 1, pp. 14–36, 2011.
[10] A. Michalas, N. Komninos, and N. Prasad, “Multiplayer game for ddos
attacks resilience in ad hoc networks,” in Wireless Communication,
Vehicular Technology, Information Theory and Aerospace Electronic
Systems Technology (Wireless VITAE), 2011 2nd International Confer-
ence on, pp. 1–5, Feb 2011.
[11] A. Michalas, N. Komninos, and N. R. Prasad, “Cryptographic puzzles
and game theory against dos and ddos attacks in networks,” International
Journal of Computer Research, vol. 19, no. 1, p. 79, 2012.
[12] “Digitalocean: Cloud computing designed for developers.”
[13] S. Tilkov and S. Vinoski, “Node. js: Using javascript to build high-
performance network programs,” IEEE Internet Computing, vol. 14,
no. 6, pp. 80–83, 2010.
[14] “Digital ocean sla.”
[15] F. A. Petitcolas, “Kerckhoffs principle,” in Encyclopedia of cryptography
and security, pp. 675–675, Springer, 2011.
[16] “Nginx — high performance load balancer, web server, reverse proxy.”
[17] “Typescript - javascript that scales.”
[18] “Pug.”
[19] “Swift.”
[20] “Tredis.”
[21] “Postgresql.”
[22] “Tmongodb for giant ideas — mongodb.”
[23] “Express - node.js web application framework.”
[24] “bluebird.”
[25] “pg-promise.”
[26] “Helmet helps you secure your express.js apps by setting various http
headers. it’s not a silver bullet, but it can help!.”
[27] “Node crypto.”
[28] “node-uuid.”
[29] P. Leach, M. Mealling, and R. Salz, “Rfc 4122: A universally unique
identifier (uuid) urn namespace, 2005,” Online: http://www. ietf. org/r-
fc/rfc4122. txt. Accessed, vol. 4, 2013.
[30] “Keychain swift.”
[31] “Alamofire.”
[32] “Openssl.”
View publication stats
[33] “Let’s encrypt.”
[34] “Htbridge.”
[35] P. Mell, T. Grance, et al., “The nist definition of cloud computing,”
2011.
[36] A. Shaw, “Data breach: from notification to prevention using pci dss,”
Colum. JL & Soc. Probs., vol. 43, p. 517, 2009.
[37] C. for Disease Control, Prevention, et al., “Hipaa privacy rule and public
health. guidance from cdc and the us department of health and human
services,” MMWR: Morbidity and mortality weekly report, vol. 52,
no. Suppl. 1, pp. 1–17, 2003.
[38] “Real-world passwords.”
[39] “Brutalis gpu.”
[40] “Hashcat.”
[41] N. Paladi, A. Michalas, and C. Gehrmann, “Domain based storage
protection with secure access control for the cloud,” in Proceedings
of the 2014 International Workshop on Security in Cloud Computing,
ASIACCS ’14, (New York, NY, USA), ACM, 2014.
[42] Y. Verginadis, A. Michalas, P. Gouvas, G. Schiefer, G. Hbsch, and
I. Paraskakis, “Paasword: A holistic data privacy and security by design
framework for cloud services,” in Proceedings of the 5th International
Conference on Cloud Computing and Services Science, pp. 206–213,
2015.
[43] N. Paladi, C. Gehrmann, and A. Michalas, “Providing user security
guarantees in public infrastructure clouds,” IEEE Transactions on Cloud
Computing, vol. PP, no. 99, pp. 1–1, 2016.
[44] Y. Verginadis, A. Michalas, P. Gouvas, G. Schiefer, G. Hübsch, and
I. Paraskakis, “Paasword: A holistic data privacy and security by design
framework for cloud services,” pp. 1–16, 2017.
[45] N. Paladi and A. Michalas, ““One of our hosts in another country”:
Challenges of data geolocation in cloud storage,” in Wireless Com-
munications, Vehicular Technology, Information Theory and Aerospace
Electronic Systems (VITAE), 2014 4th International Conference on,
pp. 1–6, May 2014.
[46] A. Michalas, “Sharing in the rain: Secure and efficient data sharing for
the cloud,” in 2016 International Conference for Internet Technology
And Secured Transactions, pp. 589–595, Dec 2016.
[47] A. Michalas and K. Y. Yigzaw, “Locless: Do you really care your cloud
files are?,” in 2016 IEEE/ACM 9th International Conference on Utility
and Cloud Computing (UCC), pp. 618–623, Dec 2015.
[48] T. Dimitriou and A. Michalas, “Multi-party trust computation in decen-
tralized environments,” in 2012 5th International Conference on New
Technologies, Mobility and Security (NTMS), pp. 1–5, May 2012.
[49] T. Dimitriou and A. Michalas, “Multi-party trust computation in decen-
tralized environments in the presence of malicious adversaries,” Ad Hoc
Networks, vol. 15, pp. 53–66, Apr. 2014.
[50] A. Michalas, V. A. Oleshchuk, N. Komninos, and N. R. Prasad, “Privacy-
preserving scheme for mobile ad hoc networks,” in Computers and
Communications (ISCC), 2011 IEEE Symposium on, pp. 752–757, June
2011.
[51] A. Michalas and N. Komninos, “The lord of the sense: A privacy
preserving reputation system for participatory sensing applications,” in
Computers and Communication (ISCC), 2014 IEEE Symposium, pp. 1–
6, IEEE, 2014.
[52] A. Michalas, M. Bakopoulos, N. Komninos, and N. R. Prasad, “Secure
amp; trusted communication in emergency situations,” in Sarnoff Sym-
posium (SARNOFF), 2012 35th IEEE, pp. 1–5, May 2012.
[53] A. Michalas and R. Dowsley, “Towards trusted ehealth services in the
cloud,” in 2015 IEEE/ACM 8th International Conference on Utility and
Cloud Computing (UCC), pp. 618–623, Dec 2015.
[54] K. Y. Yigzaw, A. Michalas, and J. G. Bellika, “Secure and scalable dedu-
plication of horizontally partitioned health data for privacy-preserving
distributed statistical computation,” BMC Medical Informatics and De-
cision Making, vol. 17, no. 1, p. 1, 2017.
[55] K. Yigzaw, A. Michalas, and J. Bellika, “Secure and scalable statistical
computation of questionnaire data in r,” IEEE Access, vol. PP, no. 99,
pp. 1–1, 2016.
[56] A. Michalas, N. Paladi, and C. Gehrmann, “Security aspects of e-health
systems migration to the cloud,” in e-Health Networking, Applications
and Services (Healthcom), 2014 IEEE 16th International Conference
on, pp. 212–218, IEEE, 2014.
[57] R. Dowsley, A. Michalas, and M. Nagel, “A report on design and
implementation of protected searchable data in iaas,” tech. rep., Swedish
Institute of Computer Science (SICS), 2016.