News Column

Patent Application Titled "Seamless Secure Private Collaboration across Trust Boundaries" Published Online

June 24, 2014

By a News Reporter-Staff News Editor at Information Technology Newsweekly -- According to news reporting originating from Washington, D.C., by VerticalNews journalists, a patent application by the inventors Stamos, Nicholas (Belmont, MA); Odnovorov, Igor (Walpole, MA), filed on September 16, 2013, was made available online on June 12, 2014.

The assignee for this patent application is nCrypted Cloud LLC.

Reporters obtained the following quote from the background information supplied by the inventors: "This patent application relates to secure, collaborative file sharing across trust boundaries and among different devices and users.

"File hosting services that offer cloud storage and file synchronization across multiple client devices are becoming an increasingly popular way to store computer files. These services allow users to create a special folder on a computer, which the service then synchronizes so that it appears to be the same folder with the same contents regardless of the particular device on which the folder is viewed. Files placed in this folder are also accessible through a website and mobile phone applications. Services of this type include Dropbox.TM., Google Drive.TM., Microsoft.TM. SkyDrive.TM., and others. The providers of these services typically offer software for different operating systems such as Microsoft Windows.TM., Apple.TM. Mac OSx.TM., Linux.TM., Android.TM., Apple iOS.TM., Blackberry.TM. OS.TM. and web browsers. The popularity of these services is no doubt due to the increasing tendency of each person to use multiple devices such as laptops, desktops, smart phones, tablets, etc. while expecting their information to be available anytime, anywhere.

"These services in effect add synchronization and sharing to simple file hosting services. Synchronization supports background distribution of files across the user's various devices, as well as revision management, so that a file edited or deleted on one machine may be recovered from any of the other synced machines. Some of these services also support multiuser version control, enabling several users to edit and repost files without overwriting versions of the same file created by other users.

"A number of innovative uses and mashups of these 'store and sync' technologies have been developed. For example, add-ons to the Dropbox Service allow users to email files, facilitate online backup using protocols such as File Transfer Protocol (FTP), provide an interface to desktop applications, and include extensions that support file synchronization with other services such as Google Docs."

In addition to obtaining background information on this patent application, VerticalNews editors also obtained the inventors' summary information for this patent application: "While these store and sync services have found widespread use and provide many advantages they are not without their shortcomings.

"One important shortcoming involves security. Some services do provide a measure of security through use of particular storage systems. For example, Dropbox uses Amazon's.TM. S3 storage system that supports Secure Sockets Layer (SSL) transfers for file synchronization via the Advanced Encryption Standard (AES). However any user that has been authorized to access another user's Dropbox folder will be granted access to all of the contents of that folder. Therefore, these services provide no easy way to manage security on a per file, or even per-folder, basis.

"The service provider also many times maintains access to end user stored data, by having access to the user's encryption keys, for the purpose of data deduplication, data visibility on web browser interface or the mining of metadata. This is clearly less than ideal from the user's perspective, who would prefer to have some assurance that their confidential information can never be compromised by the service provider.

"In addition, even if a user tries to make use of passwords to protect individual files, there is still the problem of managing distribution of the password among two or more other people who wish to collaborate on a project, the tendency of people to forget passwords over time, and other problems that invariably arise with such an approach.

"What is needed is a way to provide seamless, secure, private, collaborative file synchronization across trust boundaries. In preferred embodiments, a companion application can be provided to a store and sync service, or a modification to a store and sync service. In general, the approach stores everything that is needed to recover a protected file within the file itself, without giving away secret data needed to recover the file, including all information needed to recover the file in the event a password is lost.

"In one specific embodiment, a personal key is generated for each user. This user-specific, personal key is derived from account credentials such as an email address and password. This user specific personal key is preferably only stored on the users' device(s) and is never sent over a network to a server. Because this personal key is derived from account credentials, it can be generated and stored on any one of multiple devices for which a specific user wishes to implement the service.

"Another unique key is also created for each object, such as a file or a folder, that the user wishes to treat securely. In one example, the content of a file is secured when file is created and/or updated as follows. A unique folder key value and key identifier are generated for each folder that is to be secured. For each file in the folder a unique file ID is generated. Each such file is protected with a password which is derived from the (a) a key value that can either be (i) the user's personal key in the case of a file that is to be private or (ii) a shared key in the case of a file that is to be shared with other users, and (b) the unique file ID for the file. The password is then encrypted using a recovery key and then stored in the file itself. The file is then secured by storing the contents using a .zip archive or other file format protected with password-based file content encryption.

"This approach provides file security via (a) the access controls implemented by the store and sync service, which control access to each file and therefore also control access to the unique key for each file and (b) the fact that the personal key is only generated on the user's device and is never forwarded to a server. Further, by always carrying the information needed to recover the file within the file itself, it is always possible to recover the contents of the file from the file itself.

"In addition, a recovery key ID is preferably stored with each file to enable recovery of the file in the event that the owners' account password changes, the owner's password is lost, or in other situations.

"The recovery key and recovery key ID are personal to the owner of the file, and may be stored on a server.

"In a preferred embodiment, files that the user wishes to secure are instantiated using a digital file container (or wrapper) such as the .zip format, .pdf format, or any other standardized file format that support password-based file encryption and which can be read across many different types of devices and operating systems. The container should also provide some way to maintain metadata with each file as explained above. For example, in the case of a .zip file, a comment field is available to store this metadata.

"The metadata for each secured file may typically include the unique ID for the file, an ID for the file key, the recovery key ID and a recovery Binary Large Object ('blob') that consists of the file's password encrypted with the recovery key. Other sets of keys and blobs can also be included in the metadata, to provide recovery by corporate, enterprise and or other access levels beyond the owner's access.

"The file key and file key ID thus become a 'collaborative' key in the case of a file that is to be shared, since that information will need to be available to any other user having access to the file. More specifically, collaboration with secure file sharing across trust boundaries is also possible with this approach. Here, The generated file key and file key ID instead become shared key ID and a shared key value. These keys are then used instead of the personal keys to secure the files. Thus, when a decision is made to share particular file (or folder), these 'shared securely' keys are stored with a manifest file associated with the folder. This manifest file or configuration file thus contains the shared folder ID, the shared folder key ID and the recovery key ID.

"Certain types of file container formats (such as .zip), allow a single container to hold many files and folders and are thus preferred for providing a securely shared folder service. In this type of container, a specialized separate file can serve as a manifest file that may contain the metadata indicating the key ID for the container file. This manifest file is then accessed to obtain the information needed to access the files and file folders within the .zip archive.

".pdf type containers typically do not support multiple files or folders within each container, but they can provide additional functionality in that they inherently support granular access policies such as view, print, edit and so forth for each file.

"The approach also allows layering of additional access policies such as open enrollment, server-managed access to keys, file sharding, and so forth.


"The description below refers to the accompanying drawings, of which:

"FIG. 1 is a high-level diagram illustrating a network of data processing systems in which preferred embodiments may be implemented.

"FIGS. 2A through 2E illustrate a user's view of the contents of a file container from within the secure container management application as compared to a view from the store and sync service application.

"FIG. 3 is a flowchart of a key storage initialization process.

"FIG. 4 is a flow diagram of a password generation based on the personal or shared key value and the unique file identifier.

"FIG. 5 illustrates metadata for a .zip container in more detail.

"FIG. 6 is a flowchart of a file decryption process.

"FIG. 7 illustrates a container that supports folders in more detail

"FIG. 8 is a flowchart of an open enrollment process."

For more information, see this patent application: Stamos, Nicholas; Odnovorov, Igor. Seamless Secure Private Collaboration across Trust Boundaries. Filed September 16, 2013 and posted June 12, 2014. Patent URL:

Keywords for this news article include: nCrypted Cloud LLC, Information Technology, Information and Data Encoding and Encryption.

Our reports deliver fact-based news of research and discoveries from around the world. Copyright 2014, NewsRx LLC

For more stories covering the world of technology, please see HispanicBusiness' Tech Channel

Source: Information Technology Newsweekly

Story Tools Facebook Linkedin Twitter RSS Feed Email Alerts & Newsletters