1. Digital Vault Kick-off 02/12/2015

2.  Fast & scalable object level storage  Secure content persistence  Secure bi-directional content sharing  Secure content provenance  Shared content libraries  Private-hosted file synchronization  Built upon open source components  Basic security model with optional extensions (consumer-driven security enforcement)  Vault-in-vault concept © Trust1Team 2015 Intro Digital Vault Engine our understanding

3.  Policies for user storage quota available  API Engine available  On-premise solution  User OAuth2 consent available in existing authorization infrastructure  User authentication available in existing authentication infrastructure © Trust1Team 2015 Concept assumptions

4. © Trust1Team 2015 Concept at the center of the solution: secured content

5.  Content encryption standards X509 private keys for desktop clients PDKDF2 session keys using RSA encryption AES-256/CBC encryption for data transfer ISO-32000 AES256 encryption for PDF encryption ISO/IEC 9899:1999 Digital sign shared documents using ETSI AdES and ASiC  Adaptable feature-rich security model Optional password protection on shared link Optional expiration time on shared link Optional signing for content integrity Optional X509 public key signing for content transfer © Trust1Team 2015 Concept security Standards

6. © Trust1Team 2015 Concept security at all levels

7.  Vault Security Secured local storage Secured cloud storage Secured content transfer Trusted list of sync devices Secured token distribution Content provenance and Content integrity  Vault Archiving Content retention using Apache CMIS Content retention to private cloud distributed storage © Trust1Team 2015 Concept security at all levels

8.  Micro-service design  Stateless services design  API-first design  Behavior driven development  User-centric  Semantic Versioning © Trust1Team 2015 Concept design principles resilient elastic stateless responsive

9.  In scope – Demo DV application OAuth2 enabled Angular JS To test all endpoints with user actions: – upload, share, download,…  Synchronization client cfr. Seafile clients available OSX, Windows, Linux, terminal based Mobile Android Mobile iOS © Trust1Team 2015 Concept wireframes

10.  Mobile applications (Android & iOS) © Trust1Team 2015 Concept wireframes

11. © Trust1Team 2015 Concept architecture component model assumption: existing search engine

12. Client side (front-end) – 3 rd party web applications for a variety of devices – Demo DV application made within the scope of the project – Desktop synchronization clients – Mobile synchronization clients Server side (back-end) – Digital Vault Engine – Integration with API Engine – Integration with Search Engine Server side (storage) – Storage and storage replication (quota storage policy) – Archiving to private distributed cloud storage – Archiving to ECM via Apache Chemistry layer © Trust1Team 2015 Concept architecture component model

13.  Basic version of the DV Demo application  Connects directly to the micro-service API  Implements following user stories: 1) upload file from DV Demo app into existing DV folder 2) share file from DV Demo app => mail to user with link 3) user downloads file using the link from the received mail © Trust1Team 2015 Concept proof of Concept

14. © Trust1Team 2015 Technology file system design

15.  Files are organized into Libraries – designed for synchronization Network/storage deduplication No upload/download limit Fast upload (back-end daemons)  Data model and sync similar to GIT (Repo, Branch, Commit, FS, Block)  Selective sync library to devices  Sync with existing folder  Sync client-side end-to-end data encryption  Full platform support: Win, OSX, Linux, mobile  Share to a person or a group  Share specific content or a folder  Read-write and read-only share © Trust1Team 2015 Technology file system design

16. © Trust1Team 2015 Technology deduplication

17. © Trust1Team 2015 Technology high-level architecture

18.  Seafile C, C++ OpenSSL  Java EE JAXRS, CDI Maven Bouncy Castle Crypto API  Sync desktop clients Qt4/5 C++  Sync mobile clients Android iOS © Trust1Team 2015 Technology stack

19.  Content Integrity and Content Provenance  Archiving to cloud storage  Archiving to ECM platforms  Basic security on all levels  Customizable security © Trust1Team 2015 Technology stack innovative features in the solution Different from cloud storage solutions for personal use Open API security : every application can enforce strong security

20.  Digipolis and T1T agree on list of detailed product requirements  T1T creates product backlog based on product requirements  Sprints of 2 weeks  Sprint demo  Transparency via JIRA project  Regular sync meetings with Digipolis stakeholder © Trust1Team 2015 Approach sprint planning with monthly releases

21. sprint 1-2 password, AES folder storage Account Mgmt synch Token Distribution Content Sharing sprint 3-4 security features key store management zip creation & encryption pdf encryption sprint 5-6 content provenance archiving to ECM integration with search engine © Trust1Team 2015 Approach milestones part 1 POC 0.0.1 Version 0.0.5

22. sprint 7-8 archiving to personal cloud storage trusted devices list bug fixing sprint 9 bug fixing move to Acceptance sprint 10 move to production © Trust1Team 2015 Approach milestones part 2 Version 0.5.0 Version 1.0.0

23.  Deliverables Source code Builds Technical documentation User documentation  Project closing Hand-over to technical team User training  Duration of the project is approx 4 months © Trust1Team 2015 Approach deliverables and project closing

24. Thank you for your kind attention Do you have any questions?

25.  A typical synchronization work flow consists of the following steps: Seafile client daemon detects changes in the worktree (via inotify etc). The daemon commits the changes to the local branch. Download new changes from the master branch on the server (if any). Merge the downloaded branch into local branch (also checkout changes to worktree). Fast-forward upload local branch to server's master branch.  Custom merge algorithm Auto-sync Git is unreliable Merge after file write-protection releases lock © Trust1Team 2015 Annex 1 Synch algorithm

26. © Trust1Team 2015 Annex 2 Git approach – why?  Synchronization may be interrupted at any point by shutting down the program or computer, after reboot we lose all notifications from the OS. We need a reliable and efficient way to determine which files in the worktree has been changed (even after reboots).  Git's index file are used to do this. It caches the timestamps of every file in the worktree when the last commit is generated. So we can easily and reliably detect changed files in the worktree since the latest commit by comparing timestamps.  Another notable case is what happens if two clients try to upload to the server simultaneously. The commit procedure on the server ensures atomicity. So only one client will update the master branch successfully, while the other will fail.  The failing client will restart the sync work flow later. It will first merge the changes from the succeeded client then upload again.

27. © Trust1Team 2015 Annex 3 Low-bandwidth Network File System  Description of LBFS:  https://trust1t.atlassian.net/wiki/display/DVE/Digipolis+- +Digital+Vault+Engine+- +Presentation?preview=/51707943/52199434/lbfs.pdf https://trust1t.atlassian.net/wiki/display/DVE/Digipolis+- +Digital+Vault+Engine+- +Presentation?preview=/51707943/52199434/lbfs.pdf

28.  Sprint planning and milestones in Jira:  https://trust1t.atlassian.net/secure/RapidBoard.jspa?rapidView=69 &projectKey=DIGIDV&view=planning https://trust1t.atlassian.net/secure/RapidBoard.jspa?rapidView=69 &projectKey=DIGIDV&view=planning © Trust1Team 2015 Annex 4 Backlog

29.  https://github.com/haiwen/seafile - 3200+ stars https://github.com/haiwen/seafile  Estimated at least 200K users worldwide, mostly in Europe  Open Source Software (AGPLv2)  Available Open Source sync clients for desktop and mobile  GIT approach but enhanced for auto-sync and handling large files  Custom merge algorithm  Basic privacy protection  Efficient network transfer (LBFS-based)  Only does what it should do best - approach © Trust1Team 2015 Annex 5 Why Seafile?

30.  Automatic synchronization  Clients do not store file history, thus they avoid the overhead of storing data twice. Git is not efficient for larger files such as images.  Files are further divided into blocks for more efficient network transfer and storage usage.  File transfer can be paused and resumed.  Support for different storage backends on the server side.  Support for downloading from multiple block servers to accelerate file transfer.  More user-friendly file conflict handling. (Seafile adds the user's name as a suffix to conflicting files.)  Graceful handling of files the user modifies while auto-sync is running. Git is not designed to work in these cases. © Trust1Team 2015 Annex 6 What are the differences for Seafile vs Git?