Secure and trustworthy file sharing over cloud storage using eID tokens

1f8988da3a35433e9411f5cd6886089a?s=47 Ed Duarte
November 05, 2014

Secure and trustworthy file sharing over cloud storage using eID tokens

This presentation showcases Protbox, an open-source application that builds a secure environment on top of existing cloud storage services (e.g. Dropbox, Google Drive) without disrupting normal usage. Confidential data is encrypted and made accessible to others without requiring any extra third-party services, and access control is enforced by using national electronic identity (eID) tokens.

1f8988da3a35433e9411f5cd6886089a?s=128

Ed Duarte

November 05, 2014
Tweet

Transcript

  1. 1.

    Secure and trustworthy file sharing over cloud storage using eID

    tokens Eduardo Duarte Filipe Pinheiro André Zúquete Hélder Gomes
  2. 2.

    Protbox • System conceived for secure file sharing over cloud

    storage providers – Independent of storage providers – Independent of operating systems • Implemented in Java – Uses eIDs for personal identification • Through PKCS #11 OID 2014, Stuttgart, 5-6 Nov 2014 2
  3. 3.

    Protbox security features • Confidentiality – Storage provider has no

    access to original contents • Integrity control – Malicious or involuntary file tampering is detected • Content loss – Malicious or involuntary file deletions can be overcome • Access control – Personal authorization to access files on shared folders OID 2014, Stuttgart, 5-6 Nov 2014 3
  4. 5.

    Architectural requirements • Independence from cloud storage solutions – Protbox

    only uses local folders – Shared Folder is a local folder synchronized with a Cloud Folder by software given by the cloud provider • eID support – Protbox only requires digital signature support OID 2014, Stuttgart, 5-6 Nov 2014 5
  5. 6.

    Terminology • Protbox Pair – A pair of directories •

    Shared Folder • Prot Folder – Both local to the user • Pair Key – A symmetric key for encrypting files on a Shared Folder – Randomly generated by the first Protbox Pair created upon a Shared Folder OID 2014, Stuttgart, 5-6 Nov 2014 6
  6. 7.

    Terminology • Key Distribution Key Pair (KDKP) – Asymmetric key

    pair of a user running Protbox • Temporary • Created when Protbox starts – Public component signed with the user eID • Immediately upon creation – Usage: • Signed requests of Key Pairs • Secure communication of Key Pairs OID 2014, Stuttgart, 5-6 Nov 2014 7
  7. 8.

    Use case: 1st step • Alice and Bob want to

    share photos – In a private way • Alice makes the first move – Creates a Cloud Folder OID 2014, Stuttgart, 5-6 Nov 2014 8
  8. 9.

    Use case: 2nd step • Alice associates the Cloud Folder

    with a Prot Folder with the photos to share with Bob – Protbox populates the Cloud Folder with the encrypted versions of Alice’s photos • Alice invites Bob to share the Cloud Folder – Out of the scope of Protbox OID 2014, Stuttgart, 5-6 Nov 2014 9
  9. 10.

    Use case: 3rd step • Bob associates the Cloud Folder

    with a Prot Folder – Since the Cloud Folder is not empty, Protbox needs to get its Pair Key • Bob’s Protbox sends a Pair Key request – Through the Cloud Folder – This is a signed request • It contains the eID identity of the signer OID 2014, Stuttgart, 5-6 Nov 2014 10
  10. 11.

    Pair Key distribution protocol OID 2014, Stuttgart, 5-6 Nov 2014

    11 Alice Bob KDKP K-A K+A KDKP K-B K+B Pair Key request, signed with K-B K+B signed with Bob eID eID certificate chain Pair Key encrypted with K+B signed with K-A K+A signed with Alice eID eID certificate chain
  11. 12.

    Use case: 4th step • Alice’s Protbox pops up Bob’s

    request – Displaying Bob’s identity • Alice disagrees – The request is overlooked – Removed after a timeout • Alice agrees – Sends back a confidential reply with the Pair Key • Through the Cloud Folder • Encrypted with Bob’s KDKP public key – Signed reply • It contains the eID identity of the signer OID 2014, Stuttgart, 5-6 Nov 2014 12
  12. 13.

    Use case: 5th step • Bob’s Protbox gets the reply

    – And uses the Key Pair to populate his Prot Folder with decrypted versions of Alices’ photos • Bob adds his photos to the Prot Folder – There encrypted versions will be copied into the Cloud folder – Alice can decrypt them into her Prot Folder OID 2014, Stuttgart, 5-6 Nov 2014 13
  13. 14.

    Use case: 6th step • Alice and Bob can edit

    the photos – Changes will be propagated as usually – But ... Protbox keeps old versions is a log • Alice and Bod can delete photos – Changes will be propagated as usually – But ... Protbox also keeps a deleted version in the log • No file content lost – Unless ... the log limit is exceeded and it gets only populated with gibberish OID 2014, Stuttgart, 5-6 Nov 2014 14
  14. 15.

    Protbox control structures • Protbox Registry (PReg) – Local data

    structure – Stored in the user home directory – Contains all information about the user’s Protbox Pairs • Key Pair • File’s metadata (name, encrypted name, digests) • File’s log OID 2014, Stuttgart, 5-6 Nov 2014 15
  15. 16.

    Synchronization issues • Alice and Bob simultaneously edit the same

    photo – And simultaneously save a snapshot of it in their Prot Folder • One of them will ‘win’ – In terms of Cloud storage • But the ‘looser’ does not loose it all – Protbox can detect the conflict and rename files – If not, the ‘looser’ version exists in his own log OID 2014, Stuttgart, 5-6 Nov 2014 16
  16. 17.

    Privacy issues • The identity of Alice and Bob is

    disclosed to the Cloud provider – It can see that in the signed Pair Key requests and responses OID 2014, Stuttgart, 5-6 Nov 2014 17
  17. 18.

    Pair Key distribution issues • Anyone with access to the

    Cloud Folder can provide a signed response – With or without the right Pair Key – Responses cannot be reused • They are build upon requests • Wrong Pair Keys can be a problem – But, at least, attackers are not anonymous OID 2014, Stuttgart, 5-6 Nov 2014 18
  18. 19.

    Log management policies • On a per file basis –

    Files may have different relevancy levels • On a per user basis – Each Protbox user may have his/her own OID 2014, Stuttgart, 5-6 Nov 2014 19
  19. 20.

    Implementation • Java application – Publicly available at Github –

    Uses licensed third-party libraries – Graphical user interface • eIDs are only used when Protbox starts – A new, fresh KDKP is generated – Its public key gets signed by the eID owner OID 2014, Stuttgart, 5-6 Nov 2014 20
  20. 21.

    Implementation • Crypto used – PReg encrypted with a password-derived

    symmetric key – Files encrypted with AES CBC – File names encrypted with AES ECB • Encoded in a kind of base64 dialect – HMAC-SHA1 integrity control • Both for files and file names – RSA KDKPs – eID signatures through PKCS #11 modules OID 2014, Stuttgart, 5-6 Nov 2014 21
  21. 22.

    Experience • Operating systems – Windows, Linux, MacOS • Cloud

    folders – Dropbox – Google Drive – Microft OneDrive – SugarSync • eID solutions – Portuguese eID (Cartão de Cidadão) OID 2014, Stuttgart, 5-6 Nov 2014 22
  22. 23.

    Conclusions • Protbox enables people to share files through Cloud

    storage with security – Confidentiality – Integrity control – Identity assurance – Protection against conflicting updates – Protection against file deletions OID 2014, Stuttgart, 5-6 Nov 2014 23
  23. 24.

    Conclusions • Protbox works in different systems and with different

    Cloud storage providers – No special configurations are required • Identity assurance is provided by eID signatures – It should work for many eID solutions – Alice and Bob can use different eID solutions OID 2014, Stuttgart, 5-6 Nov 2014 24