• Created by Unknown User (szegedi), last modified on May 30, 2013

The pilot has been completed!

About

TERENA Trusted Cloud Drive is a pilot experiment developing a personal data storage service that builds on a flexible Cloud Broker Platform. The unique features of the platform are:

  • Federated access to the service
  • Metadata and storage data are kept separate
  • Storage data is encrypted and stored in the cloud
  • Metadata stored in a trusted place.
  • Various cloud storage back-ends can be brokered
  • Flexible WebDAV front-end and web app.
  • Different user platforms (Windows, MacOS, iOS, Android) are supported
  • Code and documentation is fully open-source

Phase I

April 2012 - May 2012

Completed

Phase II

June 2012 - April 2013

Completed

Pilot Recommendations

May, 2013

Completed 

Download the final report...

News

15 October 2012 - TERENA Trusted Cloud Drive pilot invites phase II participation

http://www.terena.org/news/fullstory.php?news_id=3269

23 April 2012 - New pilot project to extend TERENA's cloud activities

http://www.terena.org/news/fullstory.php?news_id=3140

Vocabulary

Cloud Broker PlatformThe Cloud Broker Platform is a flexible open-source software tool developed by UNINETT Sigma in 2010 as part of the NEON project.The platform is the basis of the TERENA Trusted Cloud Drive pilot service.
Trusted Cloud DriveTrusted Cloud Drive is a pilot service made available by TERENA for evolutionary prototyping, testing and service development purposes.
PilotA pilot experiment, also called a pilot study, is a small scale preliminary study conducted in order to evaluate feasibility, time, cost, adverse events, and effect size (statistical variability) in an attempt to predict an appropriate sample size and improve upon the study design prior to performance of a full-scale research project  . Pilot studies, therefore, may not be appropriate for case studies.
Prototype

A prototype is an early sample or model built to test a concept or process or to act as a thing to be replicated or learned from. A prototype is designed to test and trial a new design to enhance precision by system analysts and users. Prototyping serves to provide specifications for a real, working system rather than a theoretical one.

Prototype software is often referred to as alpha grade, meaning it is the first version to run. Often only a few functions are implemented, the primary focus of the alpha is to have a functional base code on to which features may be added. Once alpha grade software has most of the required features integrated into it, it becomes beta software for testing of the entire software and to adjust the program to respond correctly during situations unforeseen during development.

Evolutionary Prototyping

Evolutionary Prototyping (also known as breadboard prototyping) is quite different from Throwaway Prototyping. The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it. "The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will be built. When developing a system using Evolutionary Prototyping, the system is continually refined and rebuilt. "…evolutionary prototyping acknowledges that we do not understand all the requirements and builds only those that are well understood."

Grey-box Testing

Grey-box testing involves having knowledge of internal data structures and algorithms for purposes of designing tests, while executing those tests at the user, or black-box level.The testing procedure will include:

  • Security testing (System intrusion, Hacking, Data privacy)
  • Compatibility testing (Operating system, Web browser, API)
  • Performance testing (Load, Volume, Stress)
  • Acceptance testing (Alpha, Beta)
Service Delivery FrameworkA service delivery framework is a set of principles, standards, policies and constraints used to guide the design, development, deployment, operation and retirement of services delivered by a service provider with a view to offering a consistent service experience to a specific user community in a specific business context. An SDF is the context in which a service provider's capabilities are arranged into services.

The aim of the pilot

The aim of this pilot is to explore possible deployment scenarios for a trusted personal storage service for academia. The pilot will be built upon a federated software platform (i.e. the Cloud Broker Platform) that offers the ability to easily connect different storage back-end (both private and public cloud storage back-end are supported) and store users data in a secure and privacy preserving way (thanks to the separation of storage data and metadata as well as the built-in encryption functionality) in the cloud.

The following aspects will also be explored as part of the pilot:

(i)         Longer term sustainability for a potential service (i.e. the community);

(ii)        Legal aspects and perceived trust issues related to the storage and management of the encryption keys and metadata (i.e. the service model);

(iii)       Software scalability and performance (i.e. the code);

Although the software already offers capabilities to test different front-end applications too, this aspect will not be fully explored during the pilot. However, requirements will be collected during the pilot lifetime and recommendations on how to further improve the front-end (end-users) functionalities will be provided.

Take a look at the pilot's success measures.

Main technical characteristics of the pilot

The pilot will be prototyping and operating the Cloud Broker Platform, the open software developed by UNINETT Sigma in 2010 as part of the NEON project, at TERENA and some selected NRENs, Universities, and other institutes.This prototype software has been built with the basic idea of separating the storage data (i.e. encrypted content) from the metadata (i.e. encryption keys, filenames, size, date, etc). By keeping the metadata store “on premises” data confidentiality is guaranteed under the assumption that the premises are inside a “trusted domain” – e.g. TERENA.

Delivering the pilot

The technical part of the pilot will consist of installing all the components depicted in the picture above: namely a centralized cloud broker for the TERENA’s community (the green box depicted in the picture above), the web portal to access the system (front-end) and the storage back-end. The pilot will be carried out in two phases:

  • Phase i - Local installation of the platform at the TERENA office. During this phase the cloud broker (the elements in the green box above) will be installed and connected to a limited storage back-end offered by TERENA. A simple web portal and the necessary support for the federated access will also be developed. For this phase TERENA will sub-contract the software developer, Maarten Koopmans who will provide the necessary support for the installation. The platform will be evaluated and tested by a limited number of NRENs’ experts coordinated by TERENA.

  • Phase ii - Upon successful test of Phase i, NRENs will be invited to participate in the pilot (NRENs that have already expressed their interest in participating are HEAnet, NIIF, BELNET, PSNC, and CARNet/Srce) either adding their own cloud storage back-end and/or developing new front-end applications to the cloud broker. An additional public storage back-end will also be added. During this phase it is envisage that NRENs will offer a limited number of end-users to provide feedback on the usability of the system. Although most of the user requirements will not implemented during the pilot phase, they will help shape and understand the type of service users would be looking for.

The pilot Phase ii will be operated for a 9-month period after which an evaluation will follow to assess the success of the pilot and to agree on the following steps.

There will be three deliverables produced as part of the pilot:

  1. May 2012 – Pre-installation: System installation and technical documentation concerning the installation process (phase i).
  2. Jan 2013 – Describe possible service models: This document will describe what service(s) can be deployed and how and will detail the service scenario recommended to phase ii and the related metrics to asses the pilot. The scenario of TERENA offering this as a (sharing) service will be considered.
  3. March 2013 – Final report: Provide an evaluation of the pilot and recommendations for the next steps, based on the success of the pilot. Technical recommendations for NRENs that wish to run a local instance of the software will also be provided.

Full project description

Latest version of the full project description.

Go and visit Phase i and Phase ii

Measure of success

Explore possible deployment scenarios for a trusted personal storage service for academia.

ObjectivesMeasuresOpportunityThread

Longer term sustainability for a potential service

The community

  1. Number of alpha/beta testers (individuals) - 30
  2. Number of organizations installing the service platform at their location (other than the TERENA Secretariat) - 5
  3. Number of software developers (code co-owners other than the lead developer) who can work on the code to be proven - 3

Knowledgeable and reliable software development community around the open-source code.

Significant number of user communities, specific use cases.

Platform developer as single point of failure. Lack of development and support efforts.

No significant take up of the service platform.

Legal aspects and perceived trust issues related to the storage and management of the encryption keys and metadata

The service model

  1. Common understanding on the legal implications of storing encrypted data blob in the cloud - Whitepaper/Wiki
  2. Description of the potential service models and service delivery scenarios illustrated by use cases - Whitepaper/Wiki

Cloud platform is widely used to clearly separate the Personal Data Controller role from the Storage Data Manager role.

Organizations can pick the service model and delivery scenario that better fits to their environment and use cases.

(Legal) benefits of the platform is not understood. Perceived as yet an other personal cloud storage service.

One single service model does not fit to all organisations.

Software scalability and performance

The code

  1. Security test results (System intrusion, Hacking, Data privacy) - Done
  2. Compatibility test results (Operating system, Web browser, APIs) - Done
  3. Performance test results (Load, Volume, Stress) - Done
  4. Acceptance test results (Alpha, Beta) - Done
Platform code is robust, secure, and scalable.Platform code is weak, insecure, and rigid.
  • No labels