SECURE CLOUD STORAGE

FOR REMOTE MOBILE DATA

COLLECTION

F. Mancini, S. Gejibo, D. Grasso and K. A. Mughal

University of Bergen

Verdikt, 15.10.2013

Data Collection in Developing Countries

- Cons:

- Remote locations

- Bad infrastractures

- Limited budgets

- Pros:

- High penetration of

mobile phones

- Cheaper smart phones

Mobile Data Collection (MDC)

MDC – Data Flow

DATA MANAGER

PROJECT

SERVER DESIGN AND UPLOAD

A FORM DEFINITION

DOWNLOAD FORM

DEFINITION

UPLOAD FILLED

FORM

DATA VIEWER

ANALYSE AND

VIEW DATA

MDC – General Security Concerns

- ACCESS CONTROL

- MUTUAL AUTHENTICATION - CONFIDENTIALITY

- DATA CONFIDENTIALITY

- DATA INTEGRITY - LOCAL AUTHENTICATION - LOCAL ACCESS CONTROL

PROJECT

SERVER DESIGN AND UPLOAD

A FORM DEFINITION

DOWNLOAD FORM

DEFINITION

UPLOAD FILLED

FORM

DATA VIEWER

ANALYSE AND

VIEW DATA

More in detail - Server Deployment

Open source

server installed

on private

machine:

- Maintainance - Configuration

Closed server installed

on third party machine

and offered as a

service:

- Open an account on the server

- Pay per collector/

Data traffic

Open source

server installed on

cloud PaaS

(Google Apps):

- Configuration - Possibly free

- Easy Client

Authentication

(Oauth)

Possible Threats

• Our application runs on a third party infrastructure. What

are the risks?

• An external attacker gets hold of our data from the server

• An internal attacker monitors our data traffic

• Our data are handed over from the cloud provider to someone else

• Our application code/behaviour is modified

• Users are directed to a malicious server

• Fake data are uploaded

Possible Threats

Communication

Local data

Remote data

How?

• Encrypt your data both locally and on the server

• Keep keys away from the server and protected on the

mobile device

• Authenticate always both users and server

• Minimize the damages if a user account is compromised

• Guarantee a back-up plan for disaster recovery (you have

data from hundreds of collectors, losing a password

should not compromise the collected data)

Secure Cloud Storage Providers

General Idea

• Generate encryption key locally

• Encrypt data locally on the client

• Transfer the encrypted data to the cloud

• Keep the key

+ Cannot decrypt files

- Cannot reset/recover password

MAIN CHALLENGE

We do not trust the cloud provider

and nothing that can be used to

decrypt my files can be stored

there.

Data Upload 1. Subscribe: username + password

2. Create an account, but do not store

the password in any form on the

server, a verifier at best

1. Create a master key KM

from password

2. Create an encryption key K

3. Encrypt your files with K

4. Encrypt K with KM

1. Send your files encrypted with K

2. Forget K

Where do the different

providers differ?

- Crypto Algorithms

User Id + verifier

Data Retrivial

1. Login: username + password

1. Create a master key KM

from password

2. Download your files

3. Decrypt the encryption key

4. Decrypt you files

User Id + verifier

Problems – Weak passwords

Password verifier

PASSWORD

Steal

Guess

Encry

pts

Encrypts

Generates

Decrypts

Decrypts

PROBLEM

Using passwords for authentication is different than using passwords for encryption.

On-line vs off-line attacks.

Problems – Password Recovery

Password verifier

PASSWORD

Encry

pts

/

De

cry

pts

Encrypts/Decrypts

Password recovery

procedures do not work anymore since encryption

is now dependent on password

PROBLEM

Passwords for authentication can be reset if you prove your identity. Changing encryption key is not

possible without the old key.

Existing solutions – Weak passwords

Password verifier

PASSWORD

Decrypts

Encrypts/Decrypts

Ge

ne

rate

s

Encrypts

Passphrase

Protects locally

+ More secure

- Two passwords to remember - Portability of private key

No real solution for recovery

Password verifier

PASSWORD

Decrypts

Encrypts/Decrypts

Ge

ne

rate

s

Encrypts

Passphrase

Protects locally PASSWORD 2

Can be used to reset password

?

In the end, if the server cannot store any

key/password, it is no solution for recovery.

The user has the ultimate responsability.

Sharing

Send a link to the file with the key in clear

Send file encryption key encrypted with your friend’s public key

www.mega.nz/share.php?file=jfgba432n&key=2384ifkfvjn0w349n

Fetch Public key of your friend

Need to register with

the same provider

No much point with

encryption anymore

Back to MDCS

Only existing solution for MDC- ODK

UPLOAD

Problems

Our proposal

DATA MANAGER

PASSWORD

765349

346246

064255

765349

736734

43856

924582

134478

331351

098634

DATA VIEWER UPLOAD

ONCE UPLOAD

CONTINUOSLY

Discussion

• Remotely Secure: User credentials and cryptographic keys are distinct on the server. Obtaining one does not compromise the other. Weak password do not compromise encryption.

• Locally Pretty Secure: The master key must be stored on the phone, encrypted with some password derived key. Right now no MDC client has any form for local security.

• Flexible: More data viewers can see the uploaded forms, and collectors can edit forms after silling them. Finer access control.

• Lighter: Only one asymmetric encryption operation per form definition.

• Some limited risk: If phone is lost or stolen, and the user password is weak, the master key might be recovered, but only the forms collected by that collector might be compromised, if they are downloaded back from the server (which right now is not possible).

Recovery in MDCS

Password verifier

PASSWORD

Decrypts

Encrypts/Decrypts

Ge

ne

rate

s

Encrypts

Passphrase

Protects locally PASSWORD 2

Can be used to reset password

?

Our proposal

DATA MANAGER

PASSWORD

765349

346246

064255

765349

736734

43856

924582

134478

331351

098634

DATA VIEWER UPLOAD

ONCE UPLOAD

CONTINUOSLY

RECOVERY KEYS

Recovery in MDC

BACK UP COPY OF ALL MASTER KEYS

UPLOADED BY COLLECTORS

RECOVERY PUBLIC KEY

RECOVERY PRIVATE KEY

ENCRYPTS

STRONG SECRET ENCRYPTS

Shamir's Secret Sharing

Allows to split a secret S into n parts,

so that any subset of at least t is sufficient to reconstruct the secret.

𝑎𝑥2+ 𝑏𝑥 + 𝑐 = 0

Random Secret

p1 = 𝑥1, 𝑦1

p2 = (𝑥2, 𝑦2) .

.

pn = (𝑥𝑛, 𝑦𝑛)

Parts of the secret t=3 n=6

p1 p2 p3 p4 p5 p6

t=3

The complete picture

Conclusions

• Fairly secure solution, but probably little scalable.

• Suitable for small project, where not too much data needs to be downloaded to be analyzed

• Implementation is in progress on ODK, needs to be transparent for the user and integrate with Oauth (no dedicated user accounts)

• Why not use existing secure storage providers? • Company accounts are expensive and do not provide back-up

solution without giving a copy of the keys to the provider

• That each collector opens an account and share it with a data viewer is unfeasible

• Lack integration with current data collection apps

• If group keys are used, one compromised mobile phone, might compromise all data

The end

Thanks!