SECURE CLOUD STORAGE FOR REMOTE MOBILE DATA COLLECTION, Federico Mancini, UiB
•
3 likes•1,669 views
This document proposes a secure cloud storage solution for mobile data collection in remote areas with limited infrastructure. It discusses using encryption to securely store data in the cloud while keeping decryption keys locally on mobile devices. The proposed system encrypts data with randomly generated keys, encrypts the keys with a master key derived from the user's password, and uploads everything to the cloud. This allows access to encrypted data while preventing offline password cracking. It also includes a key recovery process using Shamir's Secret Sharing to backup encrypted master keys. Overall, the system aims to securely store collected mobile data in the cloud while protecting against various threats.
More Related Content
Similar to SECURE CLOUD STORAGE FOR REMOTE MOBILE DATA COLLECTION, Federico Mancini, UiB
Similar to SECURE CLOUD STORAGE FOR REMOTE MOBILE DATA COLLECTION, Federico Mancini, UiB (20)
More from The Research Council of Norway, IKTPLUSS
More from The Research Council of Norway, IKTPLUSS (20)
Recently uploaded
Recently uploaded (20)
SECURE CLOUD STORAGE FOR REMOTE MOBILE DATA COLLECTION, Federico Mancini, UiB
- 1. 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
- 2. Data Collection in Developing Countries - Cons: - Remote locations - Bad infrastractures - Limited budgets - Pros: - High penetration of mobile phones - Cheaper smart phones
- 3. Mobile Data Collection (MDC)
- 4. MDC – Data Flow DESIGN AND UPLOAD A FORM DEFINITION PROJECT SERVER ANALYSE AND VIEW DATA DATA VIEWER DATA MANAGER UPLOAD FILLED FORM DOWNLOAD FORM DEFINITION
- 5. MDC – General Security Concerns DESIGN AND UPLOAD A FORM DEFINITION PROJECT SERVER ANALYSE AND VIEW DATA DATA VIEWER UPLOAD FILLED FORM DOWNLOAD FORM DEFINITION - ACCESS CONTROL MUTUAL AUTHENTICATION CONFIDENTIALITY - DATA CONFIDENTIALITY DATA INTEGRITY LOCAL AUTHENTICATION LOCAL ACCESS CONTROL
- 6. 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)
- 7. 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
- 8. Possible Threats Remote data Local data Communication
- 9. 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)
- 10. Secure Cloud Storage Providers
- 11. General Idea • • Transfer the encrypted data to the cloud Keep the key + Cannot decrypt files - Cannot reset/recover password • • Generate encryption key locally Encrypt data locally on the client MAIN CHALLENGE We do not trust the cloud provider and nothing that can be used to decrypt my files can be stored there.
- 12. 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 Where do the different providers differ? - Crypto Algorithms User Id + verifier 1. Send your files encrypted with K 2. Forget K
- 13. 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
- 14. Problems – Weak passwords Decrypts Encrypts Encrypts Decrypts Password verifier Steal Guess Generates PASSWORD PROBLEM Using passwords for authentication is different than using passwords for encryption. On-line vs off-line attacks.
- 15. Problems – Password Recovery Password verifier Encrypts/ Decrypts Encrypts/Decrypts Password recovery procedures do not work anymore since encryption is now dependent on password PASSWORD PROBLEM Passwords for authentication can be reset if you prove your identity. Changing encryption key is not possible without the old key.
- 16. Existing solutions – Weak passwords + More secure - Two passwords to remember - Portability of private key Encrypts Decrypts Protects locally Passphrase Password verifier Generates Encrypts/Decrypts PASSWORD
- 17. No real solution for recovery In the end, if the server cannot store any key/password, it is no solution for recovery. The user has the ultimate responsability. Password verifier Generates Encrypts/Decrypts Encrypts Decrypts Can be used to reset password PASSWORD Protects locally Passphrase ? PASSWORD 2
- 18. Sharing No much point with encryption anymore Send a link to the file with the key in clear www.mega.nz/share.php?file=jfgba432n&key=2384ifkfvjn0w349n Need to register with the same provider Fetch Public key of your friend Send file encryption key encrypted with your friend’s public key
- 19. Back to MDCS
- 20. Only existing solution for MDC- ODK UPLOAD
- 21. Problems
- 22. Our proposal 765349 736734 43856 924582 134478 331351 098634 DATA MANAGER DATA VIEWER UPLOAD ONCE UPLOAD CONTINUOSLY 765349 346246 PASSWORD 064255
- 23. 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).
- 24. Recovery in MDCS Password verifier Generates Encrypts/Decrypts Encrypts Decrypts Can be used to reset password PASSWORD Protects locally Passphrase ? PASSWORD 2
- 25. Our proposal RECOVERY KEYS 765349 736734 43856 924582 134478 331351 098634 DATA MANAGER DATA VIEWER UPLOAD ONCE UPLOAD CONTINUOSLY 765349 346246 PASSWORD 064255
- 26. Recovery in MDC RECOVERY PRIVATE KEY ENCRYPTS STRONG SECRET BACK UP COPY OF ALL MASTER KEYS UPLOADED BY COLLECTORS ENCRYPTS RECOVERY PUBLIC KEY
- 27. 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. t=3 𝑎𝑥2 + 𝑏𝑥 + 𝑐 = 0 Secret Random t=3 n=6 p1 p2 p3 p4 p1 = 𝑥1, 𝑦1 p2 = (𝑥2, 𝑦2 ) . . pn = (𝑥𝑛, 𝑦𝑛) Parts of the secret p5 p6
- 29. 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
- 30. The end Thanks!