SECURE CLOUD STORAGE FOR REMOTE MOBILE DATA COLLECTION, Federico Mancini, UiB
-
Upload
the-research-council-of-norway-verdikt -
Category
Technology
-
view
1.283 -
download
0
description
Transcript of SECURE CLOUD STORAGE FOR REMOTE MOBILE DATA COLLECTION, Federico Mancini, UiB
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!