Software – John Haager, Cody Sandwith, Janine Terrano, Prasad Saripalli, Topia Tech Inc
Abstract for “Systems and methods for cryptographic-chain-based group membership content sharing”
“In some embodiments, the first device may create a datablock for an ordered list of data blocks so that the datablock is cryptographically linked to the preceding data block in the order. The first device might obtain an encryption key that is used to encrypt data blocks and then use the group members’ keys for encryption to create a group key. The group may have members that include the first member of the first device, as well as other members. The keys used for encrypting the encryption key could include other members’ keys. The ordered set and group key may be transmitted by the first device to a communication resource (e.g. accessible by members). The ordered set and group key may be used by other devices, which are associated with other members, to access content related to that ordered set.
Background for “Systems and methods for cryptographic-chain-based group membership content sharing”
“Security of data in Cloud and Big Data, Mobile and Internet of Things (IoT), workflows benefits from hardening, protection of data, computing resources, both online, and offline. Each workflow goes through the following stages in its data lifecycle: create, store and use (compute), share to archive, destroy, and transfer.
“Big Data Analytics (BDA), is the collection and storage large amounts of data. Analytics are run on these data stores to answer time-sensitive, specific questions. BDA is a precursor to data warehousing. Enterprise has been storing increasing amounts of data in data warehouses for many years and using analytics to support BI. Another application that uses large data sets to model complex scientific phenomena is high-performance computing (HPC). BDA applications, however, are much larger and focus on a different type of data. They are primarily unstructured data. Data warehousing and HPC typically work with structured data. They operate on a batch basis. Data warehousing is often done overnight, while HPC operations can take several days, if not weeks, to complete. BDA, on the other hand, answers questions in real time or near real-time. This is possible because BDA uses storage and compute platforms that are capable of handling large amounts of data and can scale to meet growth. To meet query speed requirements, it is preferred that the input/output operations per seconds (IOPS), are provided. The largest BDA practitioners currently address this need by using hyperscale computing environments. These environments are constructed by provisioning large numbers of commodity servers with DAS (direct-attached storage). Mirroring provides failover redundancy. These environments use Analytics engines. They typically have Peripheral Component Interconnect Express flash storage in the server, or on disk in order to reduce storage latency. These environments don’t typically use shared storage. It is unlikely that large or small enterprises would choose such high-scale platforms due to their size, cost, and scale. Other innovations are needed.”
Although commodity cloud platforms may provide the computational power required for BDA applications, they don’t have the desired large amounts of DAS. Modern big data storage systems typically use clustered or scale-out network-attached storage (NAS), or file access shared storage, which can scale up to meet increased capacity or compute requirements. These NAS use parallel file systems that are distributed across multiple storage nodes and can handle billions upon billions of files with minimal performance degradation. Such NAS can’t always be colocated with Cloud platforms which are the computing power. The Big Data and Big Compute platforms (i.e. Cloud) cannot always be colocated. Hybrid platform architectures are needed to facilitate BDA without requiring collocation of Compute or Big Data stores.
“Cloud (compute) or Big Data stores cannot all be colocated. An alternative is to keep them at different locations and have the analytics (e.g. search) workloads performed as distributed processes over Internet. This model has two problems: privacy and confidentiality, as well its sovereignty and privacy. There are also concerns about data security and protection against data breaches. Hacking, data tampering, and illicit information dissemination are all major security threats when storing or sharing data assets (such as files) in these environments. Healthcare organizations, business associates, and subcontractors who support the collection or processing of protected health information must comply with the Healthcare Insurance Portability and Accountability Act. Healthcare data breaches are common because of unencrypted or unencrypted data. Enterprise customers need advanced security and privacy services and solutions on large-scale distributed computer systems. Compliance is key to their success.
The present disclosure is about facilitating group member content sharing. A first device may create a first block of data for an ordered set (e.g., that are related to members of the group), such that the first block of data is cryptographically linked to the data block preceding it in the ordered set. A first device might obtain an encryption key that is used to encrypt information about the first data block. The encryption key can then be encrypted using keys from two or more members to create a group key. The group may have a first member who is associated with the device, a second member who is associated with the second device, and possibly other members. The encrypted encryption key can be included in the group key. Additionally, the keys used for encrypting the encryption key could include a key from the second member as well as one or more keys from the other members. The ordered set and group key may be transmitted by the first device to a communication resource (e.g. to which the second or other members have access). The ordered set and group key can be accessed by the second device to access the content of the ordered set.
The detailed description and drawings will reveal many other features and advantages of this invention. Also, it is important to understand that the detailed description as well as the general description of the invention are only examples and do not limit the scope of the invention. The singular forms of ‘a,? are used in the specification as well as in the claims. ?an,? ?an,? Unless the context requires otherwise, plural referents are allowed. The term ‘or’, as it appears in the claims and the specification, also means?and/or? means ?and/or? Unless the context clearly indicates otherwise.”
“Certain embodiments refer to distributed computing systems in which two or more computers are connected by a network link. For example, FIG. 1. The term “computer” is used in this context. The term?computer? refers to any computing device that can transmit data electronically over a network, such as a PC, server, laptop or desktop. File is an acronym that refers to any data asset. The term?file? is used to refer to any data asset, including files, folders and software, as well as data streams and data payloads. “Processors” is a generic term that can be used to refer to any data asset, including files, folders, software and virtual machines. The term?processors? may be used to refer to any processor that is implemented in any one of the following: personal computer, portable computer (PDA), workstation, or other processor-driven device. Networks may also include private networks, the Internet, or other types of networks, both wired or wireless. Node is a generic term. The term?node? as it is used herein should be taken to mean sensors, devices and systems as they are understood by one skilled in this art. The terms “segment” and “chunk?” are interchangeable. The terms?segment? und?chunk? are interchangeable. They are interchangeable. The terms’reorder? and?shuffle? are interchangeable. The terms?reorder? und?shuffle? are interchangeable. These words can be interchangeably used.”
“Those who are skilled in the art will be able to see that the systems and methods described herein can work with different system configurations. Various embodiments of the disclosure can be implemented in hardware, firmware or software, or any combination thereof. Some aspects of this disclosure can also be implemented in instructions stored on a machine readable medium that may be read by one or more processors. A machine-readable medium can include any mechanism that stores or transmits information in a form that is readable by a computer (e.g., a computing or signal transmission medium) and may also include a machinereadable transmission medium or machine-readable storage media. A machine-readable storage medium could include read only, random access memory and magnetic disk storage media. It also may contain optical storage media, optical media, flash memories, and other devices. Additionally, firmware, software routines or instructions can be described in terms of specific embodiments that may perform particular actions. It will become apparent, however, that these descriptions are only for convenience. These actions actually result from computing devices or processors or controllers executing the firmware software routines or instructions.
“Described herein are exemplary systems that can be implemented using computer software running in a processor. This program prepares a file for transporting to another computer system. This description is not meant to limit the possibilities, but it is intended to show how to accomplish the functions described herein.
The present disclosure, in various aspects, provides a method to harden the security, confidentiality and privacy of a document. This method includes: Segmenting a file at a first system into a plurality file segments; and then encrypting those file segments using a plurality encryption keys to create a corresponding plurality encrypted file segments. Each file segment is encrypted using an encryption key from the plurality encryption keys. The method may also include encrypting the plurality encryption keys to create a plurality encrypted encryption keys. The method may also include the generation of file description data that includes the plurality encryption keys. Further embodiments of the method include transferring the file description and plurality encrypted file segments from at least one source processor to at least two recipients processors. Further embodiments of the method include receiving the file description data along with the plurality encrypted file segment; decrypting each of the encrypted keys to gain the plurality; decrypting each of the encrypted file segments to obtain the plurality; and finally, combining the plurality to create a copy. The method may also include the transfer of the file description data as well as the plurality encrypted file segments. In some cases, the method is done using a file server that is connected between the first and second computers systems. The method may also include determining whether an equivalent file segment exists at the file server or second computer system and then transferring any file segments that do not have an equivalent at either the file server or second computer system. The method may also include distributing the plurality file segments amongst a number of randomly selected storage locations. The method may also include compressing each file segment. The method may also include receiving input from the user indicating the file’s identity. Some embodiments require that the user input includes associating the file to a workspace, indicating who is allowed to access it. Some embodiments use a different algorithm to generate the encryption keys for each file segment. The method may also include encrypting each encryption keys in order to create a corresponding encrypted encryption secret. The method may also include transferring multiple encrypted file segments over a network simultaneously. Some embodiments allow you to set the file size in the plurality file segments manually, automatically, or in a predetermined pattern. Each encryption key in the plurality is generated independently using a secure pseudorandom generator. The method may also include the erasure of data from at least one file or segment.
“The present disclosure offers methods for decrypting files in various aspects. This includes: receiving file description data from a first computer system that contains a plurality encrypted encryption keys and a plurality encrypted file segments; decrypting these plurality encrypted encryption keys to obtain a plurality encryption keys; decrypting each of the plurality encrypted file segments to obtain a plurality file segments; and finally, merging each file segment within the plurality file segments to create a copy. The method may also include receiving file description data from a file server that is connected to the first and second computers systems. The method may also include determining whether an equivalent of each file segment exists at the first system and then downloading encrypted file segments that correspond with file segments not yet present at that system.
“In another aspect, this disclosure provides systems for protecting the confidentiality and privacy of files. The system includes one or more processors and memory. It also contains instructions that can be executed by the processors to: Divide a file at the first computer system into multiple file segments; use a plurality encryption keys to encrypt the plurality file segments in order to create a corresponding number of encrypted file sections; generate file data that includes the encrypted encryption keys; transmit the file description data to a receiver computer system; and transfer at most of the encrypted segments to the recipient
“In another aspect, systems for decrypting files are provided by the present disclosure. The system comprises: one or multiple processors; memory; instructions executable on the one or more processors. These instructions include the following: decrypt each encrypted segment of the plurality encrypted file segments using the encryption keys associated with each segment in each file segment.
“Another aspect of the disclosure is that it provides methods for hardening security, confidentiality and privacy of files. The method includes: mapping the obfuscated file digital value to the digital value of the second computer system; transferring the obfuscated file digital values to a new computer system; and using the obfuscated file digital values as input to a search, query, etc. back to the first system.
“In some embodiments, this method also includes segmenting the file at the first computer systems into a plurality file segments; and encryption of the plurality file segments using a plurality encryption keys to create a corresponding plurality encrypted file segments. Each file segment of the plurality file segments is encrypted using an encryption key from the plurality.
“In another aspect, systems are provided for transferring files from one or multiple source computer processors at first computer systems to one or two recipient computer processors of a second system. The first computer system is networked with second computer system and includes one or several source processors that can execute one or many computer program modules. Program modules can be configured to split a file from the first computer system into multiple file segments using the one or more source processors. This process is described in Example 1. Program modules can also be configured to encrypt the plurality file segments via one or more source processors using an independently generated random encryption key for each file segment. Each randomly and independently generated encryption key is encrypted by the program modules as an associated encrypted key for each file segment. Program modules can also generate file description data, including encrypted file segment keys, using the one or more source processors. Program modules can also transfer the file description data to the other computer system via one or more source processors. Program modules can also transfer encrypted file segments via one or more source processors to the second system. The second computer system can receive file description data as well as the transferred encrypted files segments. It will then use the random and independently generated encryption key to decrypt each encrypted file segment.
“In another aspect, systems are provided for transferring files from one or multiple source computer processors at first computer systems to file transfer servers networked with first and second computer systems. The one or two source processors are configured to execute one of several computer program modules. Program modules can be configured to split a file from the first computer system into multiple file segments using the one or more source processors. Program modules can also be configured to encrypt the plurality file segments via one or more source processors using an independently generated random encryption key for each file segment. Each randomly and independently generated encryption key is encrypted by the program modules as an associated encrypted key for each file segment. Program modules can also generate file description data, including encrypted file segment keys, using the one or more source processors. Program modules can also transfer the file description data to a file transfer server via one or more source processors. Program modules can also transfer encrypted file segments via one or more source processors to the file server. The file transfer server can receive and store file description data as well as the encrypted file segments that have been transferred without knowing the contents of the file.
“Another aspect of the disclosure is that it provides systems for receiving files from a first system via one or two recipient processors at a secondary computer system. The second system being networked to the first system includes one or several recipient processors configured to execute one, or more, computer program modules. Program modules can be configured to receive encrypted file description data that describes a file as well as a plurality file segments from the first computer system, via one or more recipients computer processors. The program modules can also decrypt the plurality file segments’ identities and generate an independently generated encryption key for each file segment. Program modules can also be configured to download a plurality encrypted file segments derived from the plurality file segments. Additionally, the program modules can decrypt each plurality encrypted file segment using the independently generated random encryption key that is associated with each file segment of the plurality. Program modules can also be configured to recombine the decrypted segments using the one or more recipients computer processors into a copy file stored at the second system.
“In another aspect, systems are provided for receiving files from a server using one or more processors at a client system. The client system is connected to the server and includes one or two processors that can execute one or several computer program modules. Program modules can receive encrypted file description data that describes a plurality file segments from a file, both from the one or more processors and the file transfer server. Program modules can also decrypt the plurality file segments’ identities and generate an independently generated encryption key for each file segment. Program modules can also be configured to download a plurality encrypted file segments from the plurality file segments using the one or more processors and the file transfer server. Additionally, the program modules can decrypt each plurality encrypted file segment using the independently generated random encryption key that is associated with each file segment of the plurality. Program modules can also recombine the encrypted file segments using one or more processors to create a copy of the file on the computer system.
This document also provides systems for security hardening node-to-node data transfers across a network channel, without the need to intervene from a server. As shown in FIG. 1, the ability to segment individual files into segments can be achieved without the need for an intermediary server between two computers nodes (i.e. a sender and receiver node). 1B. 1B. File segments are encrypted with each segment being assigned a unique key. Segments are stored in non-sequential orders and each segment is assigned a unique key. The list of their locations is encrypted and saved on the client. The encrypted segments of a file as well as the encrypted instructions for reassembly are kept separately. They cannot be reassembled or decrypted by anyone without authentication. This technology is useful for data transfer between two or more computers.
“Provided are methods and systems for file segment reordering. Segmentation of files and encryption with an independent key increases security. This is because an attacker/adversary must crack every key in order to get the plaintext. Shuffling enhances security as shuffling is an extra permutation. Permutation increases diffusion in ciphertext. Diffusion is a desirable property for any cryptographic system as it increases security. Art is familiar with the confusion and diffusion concept. One can achieve diffusion using Maximum Distance Separable (MDS), matrices such as the Advanced Encryption Standard, (AES) Mix columnn step. A file can be divided into n segments so that n! There are many ways to permute or shuffle files. These may be named 1 through n! The order of permutations can be made public, so that a public key is available. The receiver would be informed of the value of i by using the public key that was given to them.
“Another aspect of the disclosure is that the file segments are distributed among multiple locations. These locations may be selected for the storage of the file segments until their use. You can choose randomly where the file segments will be stored. The locations could be randomly chosen in data storage systems such as hard drives, storage area networks (SAN), network attached storage (NAS), and storage cloud. After the files have been segmented and file sections are reordered according the systems and methods described herein, the file segments would be stored on multiple devices in multiple physical locations. These file segments could then be assembled into the file by the user or consumer system only upon request. This allows for the novel furnishing of files at any time by using file segments from multiple locations and systems.
“Another aspect of the disclosure is systems for hierarchical analysis-based sparsification of data assets for security, privacy and security. It is based upon hierarchical segment metadata analytics. These systems are able to filter only the relevant segments for reassembly and hierarchical analysis, quick search, summarization, and summary. The system’s hierarchical analysis of files improves speed and effectiveness, as well as securing the data and computation in transit and at rest. These methods include intelligent segmentation of raw data files, as well as hierarchical analysis on both raw and segment data for summarization. Hierarchical analysis algorithms, for example, can be used in bioinformatics. FASTA format is one of the most popular file formats to represent nucleotide or peptide sequences. The analysis of raw sequence data can be used to generate, test, and validate hypotheses. These systems and methods can be used to quickly analyze the metadata in sequence data files that are stored in FASTA format. These systems and methods can be used in a similar way to raw data files such as Genebank, ABI and MDL.
“Another aspect of the disclosure is that the methods are applied when the server is not secure. A user doesn’t want the server knowing her queries or the contents of the files. The user is required to provide an analytical capability. Unsecure servers do not have the key, so the system does not have access to the files. The queries are sent encrypted to ensure secrecy. The key used to encrypt data can be dependent on the query term. This allows only the data that is needed to be searched or matched to be decrypted without disclosing any other data. Inverted-indexes, hierarchical node information and all searches made on these structures can be stored in encrypted form. The client creates the hierarchy and indexes, and sends the rest of the data to the server. This complete architecture will allow for a fast and hierarchical search (fuzzy or fast search) even on insecure servers.
“Additionally there are graphical user interfaces provided herein that can be implemented on software clients, and may be displayed over an monitor. The file transfer server may also be used to serve some of the data displayed or utilized in the graphical user interface. A listing of files may be displayed on the graphical user interface for a specific workspace. A workspace can be associated with members. These members may be identified using e-mail addresses logins. A user may use the graphical user interface to manage a workspace. This includes adding members or deleting files. A user may use the graphical user interface to transfer files to another computer system. This may involve selecting a file and then adding it to the list. The file may then be processed using a method described herein. If a previous version of the file is already in the workspace, file segments may only be transferred to the file server if they contain updated data. A file may be available on the file transfer servers once it is created. The designated member may then retrieve the file by using the graphical user interface of the recipient computer system. This may allow the member to create a file copy.
“In addition, one or more designated members can be administrators of a workspace and may have greater rights than the other designated members. In an embodiment, administrators may be able to add or delete designated members using an indicator button in workspace. They may also manage actions taken by designated members. Designated users can be the owners of specific files in a file listing and may therefore have more control over those files. An embodiment may allow the owner of a file to delete it from the workspace, or prevent other users from altering the file.
“Additionally, the methods described herein allow for analysis of file metadata and data in segments that result from triple encryption, segmentation, and shuffling-based security hardening. One method could include analyzing the metadata of segments for suspicious activity and reporting it as security breaching incidents.
“Additionally, methods of triple encryption and segmentation based security hardening are provided herein on Payment Card chips at the Point of Sale(PoS), portable discs (USB), laptops, and other similar devices to lock and secure data on single computer systems or storage system at rest. These methods can also be used for Internet of Things (JOT), sensor device data streams, virtual machines (VM) files like VHD, VMDK, and the rest. An entire VM, VM appliance, or container is processed using the same triple encryption segmentation, shuffling based security harderening methods. These methods can also be used on hardware to enhance security or firmware to enhance security. They are used as secure layer middleware for Backup and Restore (SAN and NAS) and similar storage networks/devices. These methods can also be delivered as a single VM/appliance, such as a Firewall VM to data transfer processes between two or more computers. This could be Cloud or Big Data workloads. The VM can also be added to comply with a law, regulation, such as HIPAA (SOX), Sarbanes-Oxley Act, International Traffic in Arms Regulations(ITAR) and others. These methods can also be used to increase the security of data transfers at lower layers of the computer system (layers L3 through L6 of the network), for packet-level encryption, segmentation, and shuffling-based security hardening method as an appliance in the network layer.
“Additionally, herein are methods of bidirectional data transformation. The data transformation at the origin computing point is done in such a way that: the original data are first transformed so that they are obscured and retain their context and referential integrity. A mapping of the obfuscated to the original data is kept confidentially at the origin computing point. This ensures that the destination computing note, once it has received the transformed data, can still use the data to query, search or other reference back to the origin computing site. This method is used in Big Data analytics and Cloud computing to allow highly secure, private, and confidential sharing of data files and searchability.
“Additionally, herein are methods to efface, scramble or complete erase all or part of the file after satisfying certain configurable conditions in location or time, or other such as after reaching a time threshold or another location.”
“FIG. “FIG. A file transfer server 130 can receive and store files in secure segments (as explained below), so that files may be shared with recipient computer 120 on request of an authorized user at the receiver computer 120. You may appreciate that networked data transfers are a complex process. In some cases, each of the source computer systems 110, 120, and 130 file transfer servers 130 may be linked to a common network such as the internet. This network may allow data to be routed as desired by the source computer 110, 120, and 130 file transfer servers 130. One embodiment may have a source computer system 110 that includes an associated source processor 140 and a recipient computer system 120 that includes an associated recipient processor 150. You may understand that each source processor 140 and recipient process 150 could be understood to include one or more processors. These processors may be configured to run software to implement the methods and procedures described herein.
“A file 160 that is associated with source computer system110 may be found at source computer system110 (e.g. on a hard drive, solid state drive, or associated with computer system 110). A file 160 could contain a coherent set of data such as text documents (e.g..txt or.docx), etc. A file 160 could also include an image file (e.g..png or.jpg), etc. ), a spreadsheet (e.g..xlsx), and so forth. A software client 170 running on the source processor 140 may process the file 160. This may create file segments 180 which can be transferred to a client 190 running on the recipient processor 150. The file 160 could then be reconstructed as file copy 200 on storage associated with recipient computer system 120.
“A method for transferring a file can include decrypting and merging the files at the recipient computer system and segmenting and encryption of portions at the source computer system. The segmenting and encryption of the file can be considered separate from the decrypting or combining of file segments. The networked system 100 may implement the method for transferring the file. As such, the reference numbers in FIG. 1A, however, it is possible to see that the method could be used on other systems. Accordingly, FIG. FIG. 2 shows a method 210 for segmenting and encryption of the file 160. Method 210 could start at 220 and include at least 230 a user on the source computer system 110 adding file 160 to a workspace. A workspace could be described as a list of files that is shared by one or more of the source computers 110, 120 and 130. This file can be accessed only by the designated users. A user at the source system 110 could transfer the file 160 to the file transfer system 130. The file can then be retrieved later by a user at recipient system 120. Or, the file may be directly transferred between the source system 110 and the receiver system 120. In one embodiment, the user at the source computer system 110 could select the file 160 and give it to the software client 170 running on the source processor 140. The user could drag the file 160’s graphical representation onto the representation of software client 170 that is displayed on the source computer system 140. You may notice that certain parts of the graphical interface can be associated with a specific workspace. This may allow the file to be identified as belonging to particular users (e.g. designated members of the workspace or specific computer systems). The user can select the 160 file from a list of files in the library that is associated with the software client 170. Multiple files 160 can be selected in an embodiment. The multiple files may be processed in parallel or in series to transfer multiple files 160 from the source system 110 to the destination system 120.
“Once file 160 has been selected and identified by software client 170 method 210 may continue at 220, where the softwareclient 170 may collect information about file 160. This information could include, for instance, the name, type, size and date/time created as well as the date/time modified. The file 160 may also be included in the cryptographic hash. The software client 170 may also collect additional information about file 160.
Once the file information has been collected at 240 the method 210 may continue at 255. The software client 170 might divide the file 160 or a copy thereof into a plurality 180 (e.g. segments of data which could be data that make up a specific version of file 160). The process of dividing file 160 may include copying the file 160 into multiple file segments 180. For example, copying data from file 160 into multiple file segments 180. Other embodiments of the process of dividing file 160 include cutting out data from the file 160 and placing it in separate file segments 180. The software client 170 can divide the file 160 into several file segments 180 of fixed size. In one example, the software client 170 could be configured to create file sections 180 each of 500 KB. Other non-limiting embodiments may allow file segments 180 to be of different sizes, such as 128 KB or 256 KB. 64 KB and 4 MB. The size of new file segment 180 can be chosen at the time that the file 160 is updated. If a file version change causes a file segment 180 relative to the original version to be moved, the software client 170 can adjust the size surrounding indexed segments 180 to ensure that the existing file segments 180 are at the correct offset. This may help save storage space and speed up transfer times and bandwidth for clients such as software client 170 or software client 190.
One file segment 180 in an embodiment may be smaller than another 180 due to the file 160 not being divided into standard segments. The software client 170 can divide the file 160 into a fixed amount of file segments 180. The software client 170 may divide the file 160 into a fixed amount of file segments 180. In this embodiment, the threshold file size of the file 160 can determine the number of file segment 180. File segments 180 will be used if the file 160 is larger than the file 160. One example is that the file 160 could be broken into a fixed number 180 file segments if the file is smaller than a threshold. However, it may also be broken into a fixed number 180 file segments 180 if the file is larger than the threshold. One embodiment may determine the number of file segments 180 that should be used based on the file’s overall size. Another option is to use a formula calculation that uses the file size 160. The software client 170 may allow the user to choose from a variety of options regarding the number of file segment 180 to use, the size of the file segments 180, and so forth.
“The file segment 180 can be processed by the software client 170 using the source processor 140 after it has been created (e.g. copied from or created in the file 160). File segments 180 and 180 can be encrypted separately, as described in this document. This is to increase security. In various embodiments, each file segment 180 can be processed in a series (e.g. prepared and transferred) or multiple file segments 180 may all be processed in parallel. A file segment 180 can be processed in one embodiment before any file segments 180. The software client 170 could generate a file section 180 and start encrypting it, while the software client 170 generates the next file segment 180. In an alternative embodiment, the software client 170 could generate multiple file segments 180 simultaneously and encrypt them in series or parallel. It may also generate additional file segments 180 from file 160. Parallel (e.g. simultaneous) preparation or transfer of file segments 180 can reduce apparent transfer time of files 160. This is possible by using available bandwidth.
“As shown in an embodiment, the process of a file section 180 in the method 220 may include at least 260 the software client 170 collecting data about the file segment 180. The software client 170 may also be able to collect the file segment size, if it is not known. A cryptographic hash of file segment 180 may also be collected in one embodiment. This may be used to verify the transfer and decryption operations of file segment 180. It may be seen at 270 that data compression of file segment 180 may be used in certain embodiments. This may reduce file segment 180’s size, reduce bandwidth required to transfer file segments 180 to recipient processor 150, or reduce space on intermediate servers like file transfer server 130 for file segment 180 transfer. The file can be compressed using GZIP, ZIP, and so on. An embodiment would compress the file before the file segment 180 is encrypted. This could result in the encrypted segment 180 being smaller than unencrypted/clear segment 180. The file description data may include the compression algorithm used for compressing the file segment 180 in an embodiment.
“In one embodiment, an initialization vector and encryption key may be generated for file segment 180 as shown at 280. The encryption key and initialization vector can be generated randomly and the key size could vary between embodiments. In some embodiments, the key could be 128 bits or 256 bits. The initialization vector can vary between embodiments. It is possible to appreciate this. An embodiment may have an initialization vector of 128 bits. An embodiment may allow the random number generator to generate an encryption key and an initialization vector independently for each file segment 180. This means that data from other file segments 180 are not used in creating the randomly generated key or initialization vector. An algorithmically-based pseudo-random generator is one example of a random number generator that generates random numbers through repeated mathematical operations that produce randomly distributed numbers. Another embodiment of the random number generator is a true random generator, which generates random numbers by measuring non-deterministic physical phenomena (e.g. Radioactive decay, electron tunneling via diode bridges, etc
“In an embodiment, the encryption key, initialization vector, and encryption key are generated randomly for the file section 180. Method 210 may then continue at 290 with source processor 140 decrypting the file segment 180 using encryption key and initialization. The initialization vector and encryption keys may be used in an embodiment to perform encryption with cipher block chaining mode. The initialization vector may be used as an input to the encryption algorithm. This will ensure that identical or nearly identical file segments 180 are encrypted into non-identical encrypted segments 180. This could ensure that an attacker can’t use the same patterns in the encrypted segment 180 to determine information about the unencrypted segment 180. An embodiment may use cipher block chaining to encrypt the file segment 180. An electronic code book cipher may also be used in an embodiment of encryption. You may appreciate that encryption can be performed using any number of public key cryptography standards (PKCS), as described in the art. This includes, but is not limited to, using PKCS7 padding. You may appreciate that if you use separate encryption keys for each file segment 180, any compromise of one file segment 180 would only affect that segment 180 and not the rest of file segments 180. An embodiment allows for the standard and encryption algorithm to be changed across files 180 within a file 160. An embodiment may use the Advanced Encryption Standard, (?AES) to encrypt one or more file segments 180. One or more file segments 180 can be encrypted using the Advanced Encryption Standard (AES), and one or more additional file segments 180 using Data Encryption Standard(?DES). AES, DES and DESede or any other encryption algorithm can be used in an embodiment to create the encryption key for one of several file segments 180.
“Once file segment 180 has been encrypted, the software client 170 may collect the file segments 180 and 180. This is as per method 210, 300. Each of these bits of data can be used to verify that the encrypted file section 180 is transferred to the correct recipient processor 150. An embodiment may generate the hash for each file segment 180 using algorithms such SHA-256 or SHA-1. An embodiment may allow multiple hash algorithms to be used on a file 160. In this case, the file description data may include the hash algorithm for each segment 180.
“The encryption of file segments 180 can continue until all file segments 180 are processed. After all file segments 180 are processed (as determined at 310), the information from both file segments 180 before and after encryption is combined. Then, it is encrypted using a master workspace secret associated with the file. This key is used to identify users who can access the file 160, as shown at 322. An embodiment of the master workspace key may be a 128 or 256 bit AES key. The key to the master workspace may contain a 128- or 256-bit AES key. The workspace key can be shared by all users accessing a workspace. An embodiment allows two users of the source computer system 110 to have the same workspace key. The file transfer server 130 may manage and administer the workspace in an embodiment. This is described further below. The encryption of collected information can be done using cipher blockchaining (CBC) or an ECB cipher. It is possible to see that the encryption of combined files 180 and 290 may use PKCS5 padding and PKCS7 padding. An embodiment may include the file description data, which can include the encryption algorithm, block mode, e.g. CBC or ECB, and the padding mode for each file section 180.
The software client 170 will encrypt the information about file segments 180 before and after encryption. At 330, file description data may be generated that includes metadata for file 160 and a list 180 of file segments with associated information 180. It may be noted that file description data can be encrypted by the master?workspace? key. An embodiment may generate the file description data as an XML file. Example 1 shows an example of encrypted and unencrypted file description XML. It is for a file 160. In an embodiment, the file data description may include details for each file segment 180 (i.e. each?fileSegment?) The file description data may include a number of details for each file segment 180 (i.e., each?fileSegment?). Segment identifier (e.g. the?segmentID?) The?cipherTextSize tag) indicates the size of the file segment 180 encrypted (e.g. the?segmentID?). tag), The size of the file segment 180 encrypted (e.g. the?cipherTextSize?) The cryptographic key (e.g. the?key?) tag), the initialization vector (e.g., the ?initializationVector? The hash of file segment 180 encrypted (e.g. the?cipherHash?) tag. The hash of file segment 180 as encrypted (e.g. the?cipherHash? tag). tag), and an identifier of a compression algorithm (if any) used on the file segment 180 (e.g., the ?compresionAlgorithm? tag). Each of these identifying tags can be encrypted using the master workspace key in an embodiment. The file description data may include additional information about the file 160, as it will be reassembled after transfer. The file description data may include, for example, the owner information, file size, date information and a file hash (?owner?). ?size? ?date? ?date? under the?version? under the?version number? (or?hash?) can be encrypted in encrypted file description data.
“As shown in FIG. Method 210 can be continued by the source processor 170, sending the file description data the intermediate file transfer server 130. This may manage the segment transfer between the source computer 110 and the recipient system 120. An embodiment of the file transfer server 130 may include a database functionality (e.g. SQL) that may be used to facilitate data storage and retrieval functionality, as described below. The file transfer server 130 can manage file segments 180 that have been received, according to an embodiment. This is described in more detail below. The file transfer server 130 can receive the file description data and determine whether each encrypted segment 180 is present on the file server 130. This is illustrated at 350. This may be useful in situations where only a small portion of a file 160 has been modified. As such, only a subset 180 of file segments 180 could have changed from previous versions. This allows for deduplication at the file segment 180 level. A file segment 180 can be associated to a different file 160 by reference to the file segment 180 (e.g. on the transfer server 130 and the recipient computer system 120) and associating the file segment 180 with that new file 160 being transferred from source computer system 110. It may be noted that file segments 180 could be already present at file transfer 130 when multiple users have access to the workspace. This is done by referencing the existing file segment 180 (e.g. on the transfer server 130 or the recipient computer system 120) and associating that file segment 180 with the new file 160 being transferred from the source computer system 110.
“In an embodiment, the encrypted file segment 180 can be uploaded to the file server 130 if it is not at the file server 130 (e.g. as determined by the encrypted/or unencrypted haveh or other associated data), as shown at 360. If the file segment 180 is already on the file server 130, then the file transfer service 130 can mark the file segment 180 as current or in use. If a similar file 160 or versions is being used in multiple workspaces, the file segment 180 can be linked to them. An embodiment may determine whether an existing file segment 180 is being used for multiple files 160, or versions, across multiple workspaces. This will allow for common use and reduce storage requirements (e.g. at file transfer server 130). It also allows for bandwidth reduction as such file segments 180 do not need to be transferred but are simply associated with multiple files 160, or versions. This determination can be made using metadata, hashes or encrypted versions of such files depending on the user?s key usage at either the source computer system 110, or the recipient computer system 120. It is done in a way that protects the file’s secrecy on the file transfer server 130 as well as from unauthorised users. The file transfer server 130 can count the number of times that a file segment 180 has been used (e.g. across multiple files 160), to ensure that it doesn’t accidentally delete file segments 180 that are being used for other files 160. The process of transferring encrypted file segments 180 from source computer system 110 can be done in series or parallel. After there are no file segments 180 left to upload to the file server 130 (as per 370, as determined by the file description data), the upload of file segments 180 from source processor 140 to file transfer server 130 could stop at 380.
It may be noted that encrypted file segments 180 can be stored at file transfer server 130, after they have been received from source computer system 110. The encrypted file segments 180 can be stored on a number of servers, such as the cloud, in an embodiment. The file transfer server 130 can perform basic storage and retrieval functions in an embodiment. The file transfer server 130 can respond to requests from the source system 110 about the existence or absence of file segments 180. This is used, for example, to determine if file segment 180 is on file transfer server 130. An embodiment may hide from the file transfer service 130 the identity of encrypted file segments 180 by using file description data. An embodiment may reveal the number of file segment 180 in the file 160 being transmitted. However, an attacker may not be able to access the file transfer servers 130 to determine which file segments 180 are required to create the file copy 200. In an equivalent fashion, the metadata from the file server 130 that identify the name, mime type and/or size file 160 may be encrypted within the file description data. This prevents attackers or insiders from accessing the file server 130 to know such data. You may appreciate that users can choose whether to upload data such name, size and Mime type as encrypted or unencrypted in certain embodiments.
“In one embodiment, the file 160 may be transferred from the source computer 110 to the recipient system 120 with the recipient system 120 receiving encrypted file segments 180 from server 130. You may realize that there are many ways to receive file segments 180. In one embodiment, the file server 130 could notify the recipient computer 120 that new file segments 180 have been made available. This notification would be associated with a workspace to the 120 subscribers. The recipient computer system 120 could poll the file transfer server 130 to determine if an update to the file 160 is available. An embodiment may allow the recipient computer system 120 to transfer the file 160 automatically based on the transfer from source computer system 110. In an embodiment, for example, the file transfer server 130 could prompt the recipient computer 120 to start receiving file segments 180 as soon as they are transmitted from the source computer 110. One or more file segments 180 may be transferred by the source computer system 110 directly to the recipient system 130. This bypasses the file transfer server 130. In an embodiment, the file transfer functionality 130 of the file server 130 can be provided by one or both the source computer system 110 or the recipient computer system 120 to facilitate the transfer of the file 160.
“As such, the software client190 running on the recipient’s computer processor 150 at the receiver computer system 120 could be configured to perform a 390 decrypting and combing the encrypted file segments 180 thereat as illustrated in FIG. 3. An embodiment of the method 390 can begin at 400 and continue at 405 with the software client190 downloading the file description data generated by 330 and uploaded to file transfer server 130 at 350 in method 210. The file description data may be received by the software client 190 at 420. After that, the workspace key can be used to decrypt the information about file segments 180 collected by the source computer 110 at 320 in method 210.
Method 390 can continue with retrieving file segments 180 after decrypting the information about file segments 180. At 430, retrieval can include determining whether a particular segment 180 is present at the recipient system 120. Segment level deduplication may include determining whether certain file segments 180 or software client 190 are available at the recipient computer 120. In this case, it would not be necessary to re-download them. One embodiment of the method for determining whether the file segment 180 is at the recipient system 120 at 430 involves comparing the file segment identifier from the file description data with information about the file segments 180 at the recipient system 120. The file segment identifier could identify, for example, one or more of the file names of the file segments 180, 180 and 180 respectively. It may also include the encrypted hash of file segment 180 or 180. An embodiment may use the file segment ID to uniquely identify file segment 180 within the system (e.g. in the file transfer server 130). File segment identifiers in an embodiment may be quite long (e.g. 256 bits) to avoid duplicate file segment identifications. An embodiment may generate file segment identifies using the SHA256 algorithm. It may also use information about file segments 180, such as the hash of unencrypted file segments 180 and 180, as inputs.
“If the file section 180 is not available on the recipient computer system 120 then the method 390 can continue at 440 by downloading segment 180. The file segment 180 can be downloaded from the file transfer server 130. However, an embodiment of the file may be downloaded from the source computer 110, the cloud or another designated storage location. File segments 180 can be stored in a local storage cache at recipient computer system 120 or another storage location that is associated with recipient computer system 120. After the file segments 180 have been downloaded at 440 or if the file segment 180 is not already available at the recipient system 120 at 430, method 390 can continue at 450 to verify the hash of encrypted file segment 180. This may confirm that file segment 180 was downloaded correctly. The steps of downloading encrypted file segment 180 and verifying their hashs can continue until all encrypted segments 180 have been processed.
The method 390 can enter into a loop to process each encrypted file segment 180 once all file segments 180 have been received at the recipient computer system 120. As shown at 470 each file segment 180 can be decrypted using the key associated to the file segment 180 stored in encrypted file description data at 410, and decrypted by 420. Method 390 can continue at 475 to decompress the file segment 180, where the file section 180 was compressed before encryption (e.g. at 270 in method 215). The file description data may include the compression algorithm that was used to compress the file segment 180 and then decompress it. Method 390 can continue at 480 after the file segment 180 has been decrypted and decompressed, if necessary, by verifying that the unencrypted segment 180 has been properly decrypted. This is done by verifying that the hash of unencrypted segment 180 as stored in the file data. A new hash can be calculated for the file section 180 after it has been decrypted and then compared to the hash generated at the source computer 110 prior to encryption of file segment 180.
It may be noted that method 390 can continue processing all file segments 180 up to a complete set 180 of unencrypted files at the recipient computer 120 as determined at 490. Method 390 can then be continued at 500 by combining the decrypted files segments 180 into the reconstructed copy 200 at recipient computer system 120. An embodiment may determine the order of reconstruction at 500 by looking at the file description data. This may include an index number for each segment 180.
Method 390 can continue at 510 after the file copy 200 has been recreated. This involves verifying the file haveh 200 and comparing it with the original 160. (The hash of original file 160 is transferred in the file data). A cryptographic hash that was generated for the file 160 may be collected by the software client 170 on the source processor 140. This will verify that the file copy 200 was received correctly and reassembled at the recipient processor 150. The cryptographic hash can then be compared with the hash from the original file 160. Method 390 can be completed at 520 after verifying that the original 160 file on the source computer 110 has been reconstructed into the file copy 200 on recipient computer 120. This could include making the file copy 200 accessible to the user of recipient computer 120.
“As mentioned above, the software client 170 may understand different versions of files 160 to transfer file segments 180 that correspond with portions of files 160 that pertain to updated data. You may also notice that the software client 170, and/or file transfer server 130 may interpret different versions of files in order to allow for tracking updates to individual files 160. A user can retrieve a list that includes all versions of a file within a workspace in an embodiment. This could include one that has been uploaded to the file server 130 or shared between the source computer 110 and the destination computer 120. An embodiment may contain version information for a file 160, such as the file’s size, modification date and uploading user. A recipient user can request older versions of file 160 to be reconstructed as file copy 200. A user can select older versions of file 160 to be removed from their workspace.
“In one embodiment, files 160 may be shared in different versions. They could have different tags. A system tag, which may include information about where the file 160 came from or details related to data loss prevention (?DLP?) may be generated by the software clients 170. An embodiment may allow users to add user tags to a file 160 after the file has been modified by the original user. These user tags can be automatically propagated to subsequent versions of the file in an embodiment. An embodiment may make user tags public so that everyone with access to the workspace can see and modify them. These tags could include, for instance, “Proposal”,? ?For Review,? ?Final? In some embodiments. An embodiment may have user tags that are private and only visible by and/or modifiable to the user who applied the tag. An embodiment may have the originating user (e.g. the owner) as the tag’s author. The file’s owner may use tags to make the file visible to others, but not modifyable by them.
“It is possible to appreciate that some of the processes associated each of the source process 140 and the recipient processing 150 may occur at most partially in the memory/cache associated with the source or recipient processor 140, respectively, in certain embodiments. The file segments 180 generated from the file 160 may be temporarily stored in the memory or cache of the source processor 140, until they are transferred. The file segments 180 may be received by the recipient processor 150. They can then be temporarily stored in the memory or cache associated to the receiver processor 150 until they are recombined into a file copy 200.
“Those who are skilled in the art will recognize that the embodiments described herein may be implemented using a server or computer, database or communications technology. Each of these technologies implements hardware and software, or a combination thereof. The embodiments of this disclosure can be implemented as a computer program product on any computer-readable medium. This medium may include hard disks, CDROM, RAM and ROM.
“For example, FIG. FIG. 4 shows a block diagram showing a high-level block diagram of an exemplary computer 530 that may be used for various embodiments of the disclosed processes, including, but not limited, processes 210 and 390 and data storage and retrieval functions at the file transfer server 130. In some embodiments, the system that performs the processes described herein may contain all or part of the computer system 533. The computer system 530 can be linked to other computer systems 530 or associated with them in some embodiments (e.g. the source computer system 110, and/or the receiver computer system 120), via a network interface (not illustrated). The computer system 530 is enclosed in a case that houses a mainboard 540. The mainboard has a system bus 560, connection ports 560 and a processing unit (CPU) 570. A data storage device such as main memory 580 or storage drive 590 and optical drive 600 is also included. The computer system 530 may be used as the source computers system 110 and the recipient computers system 120 respectively. However, the CPU570 could serve as the source processor 140 or 150 for the recipient computer processor 150. Each of the main memory 580 and storage drive 590 as well as optical drive 600 can be constructed in any configuration. Storage drive 590, for example, may be a spinning hard drive drive or a solid-state drive. Also, optical drive 600 could include a CD drive or a DVD drive.
“Memory Bus 610 couples main memory 580 and CPU 570. The system bus550 couples storage drive 590 and optical drive 600. It also connects to connection ports 560 through CPU 570. Multiple input devices can be provided, including a mouse 620 or keyboard 630. Multiple output devices can also be provided, including a printer (not illustrated) and a video monitor 644. These output devices can be configured in an embodiment to display information about the processes described herein. This includes, but is not limited to, a graphical user interface that facilitates file transfers. You may appreciate that input and output devices can be either local to the computer 530 or remotely located (e.g., by interfacing with the computer 530 via a network or another remote connection).
Computer system 530 could be commercially available or proprietary. The computer system 530 can be a desktop unit and may be supplied by any computer system provider. Computer system 530 may be a networked computer network, in which memory storage components, such as storage drive 590 and additional CPUs 570, as well as output devices, such as printers, are provided by physically distinct computer systems that are connected to each other through the network (e.g. via portions of the networked 100). The physical components and interconnections of computer system 530 will be understood and appreciated by those skilled in the art. They can then choose a computer system that is suitable for the purposes disclosed herein.
“When computer system number 530 is activated,” preferably an operating systems 650 will load into main storage 580 during the boot sequence and prepare the computer system number 530 for operation. The simplest and most basic level of an operating system’s tasks can be divided into three categories: process management, device management (including user interface management), and memory management.
“In such a computer systems 530, the CPU570 can perform one or more of the methods, platforms, components, and modules described herein. Computer system 530 may have a computer-readable media 660 on which is stored a computer program 670 to perform the methods described herein. Computer system 530 is compatible with the format of the medium 670 and the language of program 670. The operable CPU570 can read instructions from the computer program 670, and will operate according to the disclosed methods.
“Accordingly, the CPU570 may be used in combination with other CPUs 570 to perform file encryption and segmentation, and/or the file segment recombination processes described in this invention (e.g. Methods 210 and 390. The CPU 570 can be configured to execute one to several computer program modules. Each module may be programmed to perform one or many functions of the systems described. One or more of the computer programs modules could be programmed to transmit, which can be viewed on an electronic monitor such as the video monitor (640) communicatively linked to the CPU 570, a graphic user interface (which can be interacted using the keyboard 630 and mouse 620). The graphical user interface can be used to receive user input data and allow for electronic file sharing between the source computer system 110, recipient computer system 120, as well as the file transfer server 130.
“FIG. FIG. 5A and FIG. FIG. 5A and FIG. 5B show an example of a bidirectional data transformation accelerator that can harden the security, confidentiality and privacy of files in transit within an exemplary platform. FIG. FIG. 6A and FIG. FIG. 6A and FIG. 6B show a method to harden the security, confidentiality and privacy of files. It involves mapping the digital value of the original file to the digital value of the second computer system, and then transferring the obfuscated file digital values to a second system. The second system can then use the obfuscated file digital values as input for a search, query or other reference to the first system. FIG. FIG. 7 shows an additional, non-limiting embodiment.”
“Preferred embodiments of this invention have been described and shown herein. However, it will be apparent to those skilled in art that these embodiments are only examples. The invention is open to many modifications, changes, and substitutions. In practicing the invention, there may be other embodiments than those described herein. The scope of the invention is defined by the claims below. Methods and structures that fall within these claims, and any equivalents thereof, are covered.
“Example Aspects?” File Segmentation (Triple Encryption), Obfuscation and File Segmentation.
The software and system running on the origin computing node (commonly referred to as the client), perform the operations listed herein in order for a file to be segmented, triple encrypted, and obfuscated. Segments are encrypted with randomly generated AES encryption keys. Initialization vectors are used to initialize the segments. Data masking can be used to hide their contents for extra security. File Description XML The file fields are encrypted with Workspace or Transfer Keys. These keys are shared with all users who need access to the file. When a member is invited to join a workspace, their Workspace Keys will be encrypted using the Public Key.
“In this example, it is indicated to be secure that a file be transferred. The user has the option of selecting the file from a dialog box, or dragging it onto the application window. In response to an alternative input, the user has the option to choose the file that will be automatically selected by the system. The file metadata will be collected after this indication. The file metadata includes name, last modification date and size. It also contains the cryptographic hash.
“The file payload can then be broken down into segments. The segments in the current example are the same size. It is not necessary that they be the same size. The user has the option to assign file segments randomly. You can also choose to store the segments as subsets in different locations. This dispersion provides additional security hardening. You can also redistribute the contents of segments to allow for shuffling among segments. You could distribute each ith set of segments, for example.
The unencrypted metadata of the segment is then collected. These metadata can include size and cryptographic hash (including the hashing algorithm). A supported compression algorithm is used to compress the unencrypted portion. The unencrypted data file description is shown in the following example:
”
\n
“A unique AES Segment encryption key and an initialization vector are created. You can use 128-bit keys, but you can also use longer keys if all clients support them. Other algorithms can also be used, provided that all clients support them. The algorithm 3DES is used in the example.
“The compressed, unencrypted segment is encrypted with the segment encryption key. To ensure that the segment is secure from repeated data, encryption is done using Cipher Block Chaining mode. The encrypted metadata of the segment is collected. The metadata may include size and cryptographic haveh (including the hashing algorithm chosen). The encrypted file description data in the following example is:
”
\n
“The segment metadata has been collected. The metadata includes: segment ID, position of the segment in the file, clear text size and clear text haveh, cleartext hash algorithm. Compression algorithm, segment key, segment initialization vector. Seg encryption algorithm. Seg encryption mode. Seg encryption padding mode. Cipher text size. Cipher text hash.
“The previous steps are repeated for each section.”
The file and segment metadata are then used to create the File Description XML document. For the user’s convenience, some metadata fields such as hashes with their associated hash algorithm are combined. The File Description XML Document’s sensitive fields are encrypted with the shared key that is associated with file transfer. This shared key could be either the workspace key for the workspace to which the file is being added, or a random transfer key that is stored with the command to which the file is being transmitted. Except for the segment index and the segment metadata fields themselves, all of them are encrypted. The Encrypted file description XML document is sent to the server. Each segment is uploaded on the server.”
“FIG. “FIG. FIG. 1A and FIG. FIG. 1A contains a file transfer service. FIG. FIG. 1B doesn’t include a file transfer server to transfer a file from the source computer system to the recipient computer system.”
Summary for “Systems and methods for cryptographic-chain-based group membership content sharing”
“Security of data in Cloud and Big Data, Mobile and Internet of Things (IoT), workflows benefits from hardening, protection of data, computing resources, both online, and offline. Each workflow goes through the following stages in its data lifecycle: create, store and use (compute), share to archive, destroy, and transfer.
“Big Data Analytics (BDA), is the collection and storage large amounts of data. Analytics are run on these data stores to answer time-sensitive, specific questions. BDA is a precursor to data warehousing. Enterprise has been storing increasing amounts of data in data warehouses for many years and using analytics to support BI. Another application that uses large data sets to model complex scientific phenomena is high-performance computing (HPC). BDA applications, however, are much larger and focus on a different type of data. They are primarily unstructured data. Data warehousing and HPC typically work with structured data. They operate on a batch basis. Data warehousing is often done overnight, while HPC operations can take several days, if not weeks, to complete. BDA, on the other hand, answers questions in real time or near real-time. This is possible because BDA uses storage and compute platforms that are capable of handling large amounts of data and can scale to meet growth. To meet query speed requirements, it is preferred that the input/output operations per seconds (IOPS), are provided. The largest BDA practitioners currently address this need by using hyperscale computing environments. These environments are constructed by provisioning large numbers of commodity servers with DAS (direct-attached storage). Mirroring provides failover redundancy. These environments use Analytics engines. They typically have Peripheral Component Interconnect Express flash storage in the server, or on disk in order to reduce storage latency. These environments don’t typically use shared storage. It is unlikely that large or small enterprises would choose such high-scale platforms due to their size, cost, and scale. Other innovations are needed.”
Although commodity cloud platforms may provide the computational power required for BDA applications, they don’t have the desired large amounts of DAS. Modern big data storage systems typically use clustered or scale-out network-attached storage (NAS), or file access shared storage, which can scale up to meet increased capacity or compute requirements. These NAS use parallel file systems that are distributed across multiple storage nodes and can handle billions upon billions of files with minimal performance degradation. Such NAS can’t always be colocated with Cloud platforms which are the computing power. The Big Data and Big Compute platforms (i.e. Cloud) cannot always be colocated. Hybrid platform architectures are needed to facilitate BDA without requiring collocation of Compute or Big Data stores.
“Cloud (compute) or Big Data stores cannot all be colocated. An alternative is to keep them at different locations and have the analytics (e.g. search) workloads performed as distributed processes over Internet. This model has two problems: privacy and confidentiality, as well its sovereignty and privacy. There are also concerns about data security and protection against data breaches. Hacking, data tampering, and illicit information dissemination are all major security threats when storing or sharing data assets (such as files) in these environments. Healthcare organizations, business associates, and subcontractors who support the collection or processing of protected health information must comply with the Healthcare Insurance Portability and Accountability Act. Healthcare data breaches are common because of unencrypted or unencrypted data. Enterprise customers need advanced security and privacy services and solutions on large-scale distributed computer systems. Compliance is key to their success.
The present disclosure is about facilitating group member content sharing. A first device may create a first block of data for an ordered set (e.g., that are related to members of the group), such that the first block of data is cryptographically linked to the data block preceding it in the ordered set. A first device might obtain an encryption key that is used to encrypt information about the first data block. The encryption key can then be encrypted using keys from two or more members to create a group key. The group may have a first member who is associated with the device, a second member who is associated with the second device, and possibly other members. The encrypted encryption key can be included in the group key. Additionally, the keys used for encrypting the encryption key could include a key from the second member as well as one or more keys from the other members. The ordered set and group key may be transmitted by the first device to a communication resource (e.g. to which the second or other members have access). The ordered set and group key can be accessed by the second device to access the content of the ordered set.
The detailed description and drawings will reveal many other features and advantages of this invention. Also, it is important to understand that the detailed description as well as the general description of the invention are only examples and do not limit the scope of the invention. The singular forms of ‘a,? are used in the specification as well as in the claims. ?an,? ?an,? Unless the context requires otherwise, plural referents are allowed. The term ‘or’, as it appears in the claims and the specification, also means?and/or? means ?and/or? Unless the context clearly indicates otherwise.”
“Certain embodiments refer to distributed computing systems in which two or more computers are connected by a network link. For example, FIG. 1. The term “computer” is used in this context. The term?computer? refers to any computing device that can transmit data electronically over a network, such as a PC, server, laptop or desktop. File is an acronym that refers to any data asset. The term?file? is used to refer to any data asset, including files, folders and software, as well as data streams and data payloads. “Processors” is a generic term that can be used to refer to any data asset, including files, folders, software and virtual machines. The term?processors? may be used to refer to any processor that is implemented in any one of the following: personal computer, portable computer (PDA), workstation, or other processor-driven device. Networks may also include private networks, the Internet, or other types of networks, both wired or wireless. Node is a generic term. The term?node? as it is used herein should be taken to mean sensors, devices and systems as they are understood by one skilled in this art. The terms “segment” and “chunk?” are interchangeable. The terms?segment? und?chunk? are interchangeable. They are interchangeable. The terms’reorder? and?shuffle? are interchangeable. The terms?reorder? und?shuffle? are interchangeable. These words can be interchangeably used.”
“Those who are skilled in the art will be able to see that the systems and methods described herein can work with different system configurations. Various embodiments of the disclosure can be implemented in hardware, firmware or software, or any combination thereof. Some aspects of this disclosure can also be implemented in instructions stored on a machine readable medium that may be read by one or more processors. A machine-readable medium can include any mechanism that stores or transmits information in a form that is readable by a computer (e.g., a computing or signal transmission medium) and may also include a machinereadable transmission medium or machine-readable storage media. A machine-readable storage medium could include read only, random access memory and magnetic disk storage media. It also may contain optical storage media, optical media, flash memories, and other devices. Additionally, firmware, software routines or instructions can be described in terms of specific embodiments that may perform particular actions. It will become apparent, however, that these descriptions are only for convenience. These actions actually result from computing devices or processors or controllers executing the firmware software routines or instructions.
“Described herein are exemplary systems that can be implemented using computer software running in a processor. This program prepares a file for transporting to another computer system. This description is not meant to limit the possibilities, but it is intended to show how to accomplish the functions described herein.
The present disclosure, in various aspects, provides a method to harden the security, confidentiality and privacy of a document. This method includes: Segmenting a file at a first system into a plurality file segments; and then encrypting those file segments using a plurality encryption keys to create a corresponding plurality encrypted file segments. Each file segment is encrypted using an encryption key from the plurality encryption keys. The method may also include encrypting the plurality encryption keys to create a plurality encrypted encryption keys. The method may also include the generation of file description data that includes the plurality encryption keys. Further embodiments of the method include transferring the file description and plurality encrypted file segments from at least one source processor to at least two recipients processors. Further embodiments of the method include receiving the file description data along with the plurality encrypted file segment; decrypting each of the encrypted keys to gain the plurality; decrypting each of the encrypted file segments to obtain the plurality; and finally, combining the plurality to create a copy. The method may also include the transfer of the file description data as well as the plurality encrypted file segments. In some cases, the method is done using a file server that is connected between the first and second computers systems. The method may also include determining whether an equivalent file segment exists at the file server or second computer system and then transferring any file segments that do not have an equivalent at either the file server or second computer system. The method may also include distributing the plurality file segments amongst a number of randomly selected storage locations. The method may also include compressing each file segment. The method may also include receiving input from the user indicating the file’s identity. Some embodiments require that the user input includes associating the file to a workspace, indicating who is allowed to access it. Some embodiments use a different algorithm to generate the encryption keys for each file segment. The method may also include encrypting each encryption keys in order to create a corresponding encrypted encryption secret. The method may also include transferring multiple encrypted file segments over a network simultaneously. Some embodiments allow you to set the file size in the plurality file segments manually, automatically, or in a predetermined pattern. Each encryption key in the plurality is generated independently using a secure pseudorandom generator. The method may also include the erasure of data from at least one file or segment.
“The present disclosure offers methods for decrypting files in various aspects. This includes: receiving file description data from a first computer system that contains a plurality encrypted encryption keys and a plurality encrypted file segments; decrypting these plurality encrypted encryption keys to obtain a plurality encryption keys; decrypting each of the plurality encrypted file segments to obtain a plurality file segments; and finally, merging each file segment within the plurality file segments to create a copy. The method may also include receiving file description data from a file server that is connected to the first and second computers systems. The method may also include determining whether an equivalent of each file segment exists at the first system and then downloading encrypted file segments that correspond with file segments not yet present at that system.
“In another aspect, this disclosure provides systems for protecting the confidentiality and privacy of files. The system includes one or more processors and memory. It also contains instructions that can be executed by the processors to: Divide a file at the first computer system into multiple file segments; use a plurality encryption keys to encrypt the plurality file segments in order to create a corresponding number of encrypted file sections; generate file data that includes the encrypted encryption keys; transmit the file description data to a receiver computer system; and transfer at most of the encrypted segments to the recipient
“In another aspect, systems for decrypting files are provided by the present disclosure. The system comprises: one or multiple processors; memory; instructions executable on the one or more processors. These instructions include the following: decrypt each encrypted segment of the plurality encrypted file segments using the encryption keys associated with each segment in each file segment.
“Another aspect of the disclosure is that it provides methods for hardening security, confidentiality and privacy of files. The method includes: mapping the obfuscated file digital value to the digital value of the second computer system; transferring the obfuscated file digital values to a new computer system; and using the obfuscated file digital values as input to a search, query, etc. back to the first system.
“In some embodiments, this method also includes segmenting the file at the first computer systems into a plurality file segments; and encryption of the plurality file segments using a plurality encryption keys to create a corresponding plurality encrypted file segments. Each file segment of the plurality file segments is encrypted using an encryption key from the plurality.
“In another aspect, systems are provided for transferring files from one or multiple source computer processors at first computer systems to one or two recipient computer processors of a second system. The first computer system is networked with second computer system and includes one or several source processors that can execute one or many computer program modules. Program modules can be configured to split a file from the first computer system into multiple file segments using the one or more source processors. This process is described in Example 1. Program modules can also be configured to encrypt the plurality file segments via one or more source processors using an independently generated random encryption key for each file segment. Each randomly and independently generated encryption key is encrypted by the program modules as an associated encrypted key for each file segment. Program modules can also generate file description data, including encrypted file segment keys, using the one or more source processors. Program modules can also transfer the file description data to the other computer system via one or more source processors. Program modules can also transfer encrypted file segments via one or more source processors to the second system. The second computer system can receive file description data as well as the transferred encrypted files segments. It will then use the random and independently generated encryption key to decrypt each encrypted file segment.
“In another aspect, systems are provided for transferring files from one or multiple source computer processors at first computer systems to file transfer servers networked with first and second computer systems. The one or two source processors are configured to execute one of several computer program modules. Program modules can be configured to split a file from the first computer system into multiple file segments using the one or more source processors. Program modules can also be configured to encrypt the plurality file segments via one or more source processors using an independently generated random encryption key for each file segment. Each randomly and independently generated encryption key is encrypted by the program modules as an associated encrypted key for each file segment. Program modules can also generate file description data, including encrypted file segment keys, using the one or more source processors. Program modules can also transfer the file description data to a file transfer server via one or more source processors. Program modules can also transfer encrypted file segments via one or more source processors to the file server. The file transfer server can receive and store file description data as well as the encrypted file segments that have been transferred without knowing the contents of the file.
“Another aspect of the disclosure is that it provides systems for receiving files from a first system via one or two recipient processors at a secondary computer system. The second system being networked to the first system includes one or several recipient processors configured to execute one, or more, computer program modules. Program modules can be configured to receive encrypted file description data that describes a file as well as a plurality file segments from the first computer system, via one or more recipients computer processors. The program modules can also decrypt the plurality file segments’ identities and generate an independently generated encryption key for each file segment. Program modules can also be configured to download a plurality encrypted file segments derived from the plurality file segments. Additionally, the program modules can decrypt each plurality encrypted file segment using the independently generated random encryption key that is associated with each file segment of the plurality. Program modules can also be configured to recombine the decrypted segments using the one or more recipients computer processors into a copy file stored at the second system.
“In another aspect, systems are provided for receiving files from a server using one or more processors at a client system. The client system is connected to the server and includes one or two processors that can execute one or several computer program modules. Program modules can receive encrypted file description data that describes a plurality file segments from a file, both from the one or more processors and the file transfer server. Program modules can also decrypt the plurality file segments’ identities and generate an independently generated encryption key for each file segment. Program modules can also be configured to download a plurality encrypted file segments from the plurality file segments using the one or more processors and the file transfer server. Additionally, the program modules can decrypt each plurality encrypted file segment using the independently generated random encryption key that is associated with each file segment of the plurality. Program modules can also recombine the encrypted file segments using one or more processors to create a copy of the file on the computer system.
This document also provides systems for security hardening node-to-node data transfers across a network channel, without the need to intervene from a server. As shown in FIG. 1, the ability to segment individual files into segments can be achieved without the need for an intermediary server between two computers nodes (i.e. a sender and receiver node). 1B. 1B. File segments are encrypted with each segment being assigned a unique key. Segments are stored in non-sequential orders and each segment is assigned a unique key. The list of their locations is encrypted and saved on the client. The encrypted segments of a file as well as the encrypted instructions for reassembly are kept separately. They cannot be reassembled or decrypted by anyone without authentication. This technology is useful for data transfer between two or more computers.
“Provided are methods and systems for file segment reordering. Segmentation of files and encryption with an independent key increases security. This is because an attacker/adversary must crack every key in order to get the plaintext. Shuffling enhances security as shuffling is an extra permutation. Permutation increases diffusion in ciphertext. Diffusion is a desirable property for any cryptographic system as it increases security. Art is familiar with the confusion and diffusion concept. One can achieve diffusion using Maximum Distance Separable (MDS), matrices such as the Advanced Encryption Standard, (AES) Mix columnn step. A file can be divided into n segments so that n! There are many ways to permute or shuffle files. These may be named 1 through n! The order of permutations can be made public, so that a public key is available. The receiver would be informed of the value of i by using the public key that was given to them.
“Another aspect of the disclosure is that the file segments are distributed among multiple locations. These locations may be selected for the storage of the file segments until their use. You can choose randomly where the file segments will be stored. The locations could be randomly chosen in data storage systems such as hard drives, storage area networks (SAN), network attached storage (NAS), and storage cloud. After the files have been segmented and file sections are reordered according the systems and methods described herein, the file segments would be stored on multiple devices in multiple physical locations. These file segments could then be assembled into the file by the user or consumer system only upon request. This allows for the novel furnishing of files at any time by using file segments from multiple locations and systems.
“Another aspect of the disclosure is systems for hierarchical analysis-based sparsification of data assets for security, privacy and security. It is based upon hierarchical segment metadata analytics. These systems are able to filter only the relevant segments for reassembly and hierarchical analysis, quick search, summarization, and summary. The system’s hierarchical analysis of files improves speed and effectiveness, as well as securing the data and computation in transit and at rest. These methods include intelligent segmentation of raw data files, as well as hierarchical analysis on both raw and segment data for summarization. Hierarchical analysis algorithms, for example, can be used in bioinformatics. FASTA format is one of the most popular file formats to represent nucleotide or peptide sequences. The analysis of raw sequence data can be used to generate, test, and validate hypotheses. These systems and methods can be used to quickly analyze the metadata in sequence data files that are stored in FASTA format. These systems and methods can be used in a similar way to raw data files such as Genebank, ABI and MDL.
“Another aspect of the disclosure is that the methods are applied when the server is not secure. A user doesn’t want the server knowing her queries or the contents of the files. The user is required to provide an analytical capability. Unsecure servers do not have the key, so the system does not have access to the files. The queries are sent encrypted to ensure secrecy. The key used to encrypt data can be dependent on the query term. This allows only the data that is needed to be searched or matched to be decrypted without disclosing any other data. Inverted-indexes, hierarchical node information and all searches made on these structures can be stored in encrypted form. The client creates the hierarchy and indexes, and sends the rest of the data to the server. This complete architecture will allow for a fast and hierarchical search (fuzzy or fast search) even on insecure servers.
“Additionally there are graphical user interfaces provided herein that can be implemented on software clients, and may be displayed over an monitor. The file transfer server may also be used to serve some of the data displayed or utilized in the graphical user interface. A listing of files may be displayed on the graphical user interface for a specific workspace. A workspace can be associated with members. These members may be identified using e-mail addresses logins. A user may use the graphical user interface to manage a workspace. This includes adding members or deleting files. A user may use the graphical user interface to transfer files to another computer system. This may involve selecting a file and then adding it to the list. The file may then be processed using a method described herein. If a previous version of the file is already in the workspace, file segments may only be transferred to the file server if they contain updated data. A file may be available on the file transfer servers once it is created. The designated member may then retrieve the file by using the graphical user interface of the recipient computer system. This may allow the member to create a file copy.
“In addition, one or more designated members can be administrators of a workspace and may have greater rights than the other designated members. In an embodiment, administrators may be able to add or delete designated members using an indicator button in workspace. They may also manage actions taken by designated members. Designated users can be the owners of specific files in a file listing and may therefore have more control over those files. An embodiment may allow the owner of a file to delete it from the workspace, or prevent other users from altering the file.
“Additionally, the methods described herein allow for analysis of file metadata and data in segments that result from triple encryption, segmentation, and shuffling-based security hardening. One method could include analyzing the metadata of segments for suspicious activity and reporting it as security breaching incidents.
“Additionally, methods of triple encryption and segmentation based security hardening are provided herein on Payment Card chips at the Point of Sale(PoS), portable discs (USB), laptops, and other similar devices to lock and secure data on single computer systems or storage system at rest. These methods can also be used for Internet of Things (JOT), sensor device data streams, virtual machines (VM) files like VHD, VMDK, and the rest. An entire VM, VM appliance, or container is processed using the same triple encryption segmentation, shuffling based security harderening methods. These methods can also be used on hardware to enhance security or firmware to enhance security. They are used as secure layer middleware for Backup and Restore (SAN and NAS) and similar storage networks/devices. These methods can also be delivered as a single VM/appliance, such as a Firewall VM to data transfer processes between two or more computers. This could be Cloud or Big Data workloads. The VM can also be added to comply with a law, regulation, such as HIPAA (SOX), Sarbanes-Oxley Act, International Traffic in Arms Regulations(ITAR) and others. These methods can also be used to increase the security of data transfers at lower layers of the computer system (layers L3 through L6 of the network), for packet-level encryption, segmentation, and shuffling-based security hardening method as an appliance in the network layer.
“Additionally, herein are methods of bidirectional data transformation. The data transformation at the origin computing point is done in such a way that: the original data are first transformed so that they are obscured and retain their context and referential integrity. A mapping of the obfuscated to the original data is kept confidentially at the origin computing point. This ensures that the destination computing note, once it has received the transformed data, can still use the data to query, search or other reference back to the origin computing site. This method is used in Big Data analytics and Cloud computing to allow highly secure, private, and confidential sharing of data files and searchability.
“Additionally, herein are methods to efface, scramble or complete erase all or part of the file after satisfying certain configurable conditions in location or time, or other such as after reaching a time threshold or another location.”
“FIG. “FIG. A file transfer server 130 can receive and store files in secure segments (as explained below), so that files may be shared with recipient computer 120 on request of an authorized user at the receiver computer 120. You may appreciate that networked data transfers are a complex process. In some cases, each of the source computer systems 110, 120, and 130 file transfer servers 130 may be linked to a common network such as the internet. This network may allow data to be routed as desired by the source computer 110, 120, and 130 file transfer servers 130. One embodiment may have a source computer system 110 that includes an associated source processor 140 and a recipient computer system 120 that includes an associated recipient processor 150. You may understand that each source processor 140 and recipient process 150 could be understood to include one or more processors. These processors may be configured to run software to implement the methods and procedures described herein.
“A file 160 that is associated with source computer system110 may be found at source computer system110 (e.g. on a hard drive, solid state drive, or associated with computer system 110). A file 160 could contain a coherent set of data such as text documents (e.g..txt or.docx), etc. A file 160 could also include an image file (e.g..png or.jpg), etc. ), a spreadsheet (e.g..xlsx), and so forth. A software client 170 running on the source processor 140 may process the file 160. This may create file segments 180 which can be transferred to a client 190 running on the recipient processor 150. The file 160 could then be reconstructed as file copy 200 on storage associated with recipient computer system 120.
“A method for transferring a file can include decrypting and merging the files at the recipient computer system and segmenting and encryption of portions at the source computer system. The segmenting and encryption of the file can be considered separate from the decrypting or combining of file segments. The networked system 100 may implement the method for transferring the file. As such, the reference numbers in FIG. 1A, however, it is possible to see that the method could be used on other systems. Accordingly, FIG. FIG. 2 shows a method 210 for segmenting and encryption of the file 160. Method 210 could start at 220 and include at least 230 a user on the source computer system 110 adding file 160 to a workspace. A workspace could be described as a list of files that is shared by one or more of the source computers 110, 120 and 130. This file can be accessed only by the designated users. A user at the source system 110 could transfer the file 160 to the file transfer system 130. The file can then be retrieved later by a user at recipient system 120. Or, the file may be directly transferred between the source system 110 and the receiver system 120. In one embodiment, the user at the source computer system 110 could select the file 160 and give it to the software client 170 running on the source processor 140. The user could drag the file 160’s graphical representation onto the representation of software client 170 that is displayed on the source computer system 140. You may notice that certain parts of the graphical interface can be associated with a specific workspace. This may allow the file to be identified as belonging to particular users (e.g. designated members of the workspace or specific computer systems). The user can select the 160 file from a list of files in the library that is associated with the software client 170. Multiple files 160 can be selected in an embodiment. The multiple files may be processed in parallel or in series to transfer multiple files 160 from the source system 110 to the destination system 120.
“Once file 160 has been selected and identified by software client 170 method 210 may continue at 220, where the softwareclient 170 may collect information about file 160. This information could include, for instance, the name, type, size and date/time created as well as the date/time modified. The file 160 may also be included in the cryptographic hash. The software client 170 may also collect additional information about file 160.
Once the file information has been collected at 240 the method 210 may continue at 255. The software client 170 might divide the file 160 or a copy thereof into a plurality 180 (e.g. segments of data which could be data that make up a specific version of file 160). The process of dividing file 160 may include copying the file 160 into multiple file segments 180. For example, copying data from file 160 into multiple file segments 180. Other embodiments of the process of dividing file 160 include cutting out data from the file 160 and placing it in separate file segments 180. The software client 170 can divide the file 160 into several file segments 180 of fixed size. In one example, the software client 170 could be configured to create file sections 180 each of 500 KB. Other non-limiting embodiments may allow file segments 180 to be of different sizes, such as 128 KB or 256 KB. 64 KB and 4 MB. The size of new file segment 180 can be chosen at the time that the file 160 is updated. If a file version change causes a file segment 180 relative to the original version to be moved, the software client 170 can adjust the size surrounding indexed segments 180 to ensure that the existing file segments 180 are at the correct offset. This may help save storage space and speed up transfer times and bandwidth for clients such as software client 170 or software client 190.
One file segment 180 in an embodiment may be smaller than another 180 due to the file 160 not being divided into standard segments. The software client 170 can divide the file 160 into a fixed amount of file segments 180. The software client 170 may divide the file 160 into a fixed amount of file segments 180. In this embodiment, the threshold file size of the file 160 can determine the number of file segment 180. File segments 180 will be used if the file 160 is larger than the file 160. One example is that the file 160 could be broken into a fixed number 180 file segments if the file is smaller than a threshold. However, it may also be broken into a fixed number 180 file segments 180 if the file is larger than the threshold. One embodiment may determine the number of file segments 180 that should be used based on the file’s overall size. Another option is to use a formula calculation that uses the file size 160. The software client 170 may allow the user to choose from a variety of options regarding the number of file segment 180 to use, the size of the file segments 180, and so forth.
“The file segment 180 can be processed by the software client 170 using the source processor 140 after it has been created (e.g. copied from or created in the file 160). File segments 180 and 180 can be encrypted separately, as described in this document. This is to increase security. In various embodiments, each file segment 180 can be processed in a series (e.g. prepared and transferred) or multiple file segments 180 may all be processed in parallel. A file segment 180 can be processed in one embodiment before any file segments 180. The software client 170 could generate a file section 180 and start encrypting it, while the software client 170 generates the next file segment 180. In an alternative embodiment, the software client 170 could generate multiple file segments 180 simultaneously and encrypt them in series or parallel. It may also generate additional file segments 180 from file 160. Parallel (e.g. simultaneous) preparation or transfer of file segments 180 can reduce apparent transfer time of files 160. This is possible by using available bandwidth.
“As shown in an embodiment, the process of a file section 180 in the method 220 may include at least 260 the software client 170 collecting data about the file segment 180. The software client 170 may also be able to collect the file segment size, if it is not known. A cryptographic hash of file segment 180 may also be collected in one embodiment. This may be used to verify the transfer and decryption operations of file segment 180. It may be seen at 270 that data compression of file segment 180 may be used in certain embodiments. This may reduce file segment 180’s size, reduce bandwidth required to transfer file segments 180 to recipient processor 150, or reduce space on intermediate servers like file transfer server 130 for file segment 180 transfer. The file can be compressed using GZIP, ZIP, and so on. An embodiment would compress the file before the file segment 180 is encrypted. This could result in the encrypted segment 180 being smaller than unencrypted/clear segment 180. The file description data may include the compression algorithm used for compressing the file segment 180 in an embodiment.
“In one embodiment, an initialization vector and encryption key may be generated for file segment 180 as shown at 280. The encryption key and initialization vector can be generated randomly and the key size could vary between embodiments. In some embodiments, the key could be 128 bits or 256 bits. The initialization vector can vary between embodiments. It is possible to appreciate this. An embodiment may have an initialization vector of 128 bits. An embodiment may allow the random number generator to generate an encryption key and an initialization vector independently for each file segment 180. This means that data from other file segments 180 are not used in creating the randomly generated key or initialization vector. An algorithmically-based pseudo-random generator is one example of a random number generator that generates random numbers through repeated mathematical operations that produce randomly distributed numbers. Another embodiment of the random number generator is a true random generator, which generates random numbers by measuring non-deterministic physical phenomena (e.g. Radioactive decay, electron tunneling via diode bridges, etc
“In an embodiment, the encryption key, initialization vector, and encryption key are generated randomly for the file section 180. Method 210 may then continue at 290 with source processor 140 decrypting the file segment 180 using encryption key and initialization. The initialization vector and encryption keys may be used in an embodiment to perform encryption with cipher block chaining mode. The initialization vector may be used as an input to the encryption algorithm. This will ensure that identical or nearly identical file segments 180 are encrypted into non-identical encrypted segments 180. This could ensure that an attacker can’t use the same patterns in the encrypted segment 180 to determine information about the unencrypted segment 180. An embodiment may use cipher block chaining to encrypt the file segment 180. An electronic code book cipher may also be used in an embodiment of encryption. You may appreciate that encryption can be performed using any number of public key cryptography standards (PKCS), as described in the art. This includes, but is not limited to, using PKCS7 padding. You may appreciate that if you use separate encryption keys for each file segment 180, any compromise of one file segment 180 would only affect that segment 180 and not the rest of file segments 180. An embodiment allows for the standard and encryption algorithm to be changed across files 180 within a file 160. An embodiment may use the Advanced Encryption Standard, (?AES) to encrypt one or more file segments 180. One or more file segments 180 can be encrypted using the Advanced Encryption Standard (AES), and one or more additional file segments 180 using Data Encryption Standard(?DES). AES, DES and DESede or any other encryption algorithm can be used in an embodiment to create the encryption key for one of several file segments 180.
“Once file segment 180 has been encrypted, the software client 170 may collect the file segments 180 and 180. This is as per method 210, 300. Each of these bits of data can be used to verify that the encrypted file section 180 is transferred to the correct recipient processor 150. An embodiment may generate the hash for each file segment 180 using algorithms such SHA-256 or SHA-1. An embodiment may allow multiple hash algorithms to be used on a file 160. In this case, the file description data may include the hash algorithm for each segment 180.
“The encryption of file segments 180 can continue until all file segments 180 are processed. After all file segments 180 are processed (as determined at 310), the information from both file segments 180 before and after encryption is combined. Then, it is encrypted using a master workspace secret associated with the file. This key is used to identify users who can access the file 160, as shown at 322. An embodiment of the master workspace key may be a 128 or 256 bit AES key. The key to the master workspace may contain a 128- or 256-bit AES key. The workspace key can be shared by all users accessing a workspace. An embodiment allows two users of the source computer system 110 to have the same workspace key. The file transfer server 130 may manage and administer the workspace in an embodiment. This is described further below. The encryption of collected information can be done using cipher blockchaining (CBC) or an ECB cipher. It is possible to see that the encryption of combined files 180 and 290 may use PKCS5 padding and PKCS7 padding. An embodiment may include the file description data, which can include the encryption algorithm, block mode, e.g. CBC or ECB, and the padding mode for each file section 180.
The software client 170 will encrypt the information about file segments 180 before and after encryption. At 330, file description data may be generated that includes metadata for file 160 and a list 180 of file segments with associated information 180. It may be noted that file description data can be encrypted by the master?workspace? key. An embodiment may generate the file description data as an XML file. Example 1 shows an example of encrypted and unencrypted file description XML. It is for a file 160. In an embodiment, the file data description may include details for each file segment 180 (i.e. each?fileSegment?) The file description data may include a number of details for each file segment 180 (i.e., each?fileSegment?). Segment identifier (e.g. the?segmentID?) The?cipherTextSize tag) indicates the size of the file segment 180 encrypted (e.g. the?segmentID?). tag), The size of the file segment 180 encrypted (e.g. the?cipherTextSize?) The cryptographic key (e.g. the?key?) tag), the initialization vector (e.g., the ?initializationVector? The hash of file segment 180 encrypted (e.g. the?cipherHash?) tag. The hash of file segment 180 as encrypted (e.g. the?cipherHash? tag). tag), and an identifier of a compression algorithm (if any) used on the file segment 180 (e.g., the ?compresionAlgorithm? tag). Each of these identifying tags can be encrypted using the master workspace key in an embodiment. The file description data may include additional information about the file 160, as it will be reassembled after transfer. The file description data may include, for example, the owner information, file size, date information and a file hash (?owner?). ?size? ?date? ?date? under the?version? under the?version number? (or?hash?) can be encrypted in encrypted file description data.
“As shown in FIG. Method 210 can be continued by the source processor 170, sending the file description data the intermediate file transfer server 130. This may manage the segment transfer between the source computer 110 and the recipient system 120. An embodiment of the file transfer server 130 may include a database functionality (e.g. SQL) that may be used to facilitate data storage and retrieval functionality, as described below. The file transfer server 130 can manage file segments 180 that have been received, according to an embodiment. This is described in more detail below. The file transfer server 130 can receive the file description data and determine whether each encrypted segment 180 is present on the file server 130. This is illustrated at 350. This may be useful in situations where only a small portion of a file 160 has been modified. As such, only a subset 180 of file segments 180 could have changed from previous versions. This allows for deduplication at the file segment 180 level. A file segment 180 can be associated to a different file 160 by reference to the file segment 180 (e.g. on the transfer server 130 and the recipient computer system 120) and associating the file segment 180 with that new file 160 being transferred from source computer system 110. It may be noted that file segments 180 could be already present at file transfer 130 when multiple users have access to the workspace. This is done by referencing the existing file segment 180 (e.g. on the transfer server 130 or the recipient computer system 120) and associating that file segment 180 with the new file 160 being transferred from the source computer system 110.
“In an embodiment, the encrypted file segment 180 can be uploaded to the file server 130 if it is not at the file server 130 (e.g. as determined by the encrypted/or unencrypted haveh or other associated data), as shown at 360. If the file segment 180 is already on the file server 130, then the file transfer service 130 can mark the file segment 180 as current or in use. If a similar file 160 or versions is being used in multiple workspaces, the file segment 180 can be linked to them. An embodiment may determine whether an existing file segment 180 is being used for multiple files 160, or versions, across multiple workspaces. This will allow for common use and reduce storage requirements (e.g. at file transfer server 130). It also allows for bandwidth reduction as such file segments 180 do not need to be transferred but are simply associated with multiple files 160, or versions. This determination can be made using metadata, hashes or encrypted versions of such files depending on the user?s key usage at either the source computer system 110, or the recipient computer system 120. It is done in a way that protects the file’s secrecy on the file transfer server 130 as well as from unauthorised users. The file transfer server 130 can count the number of times that a file segment 180 has been used (e.g. across multiple files 160), to ensure that it doesn’t accidentally delete file segments 180 that are being used for other files 160. The process of transferring encrypted file segments 180 from source computer system 110 can be done in series or parallel. After there are no file segments 180 left to upload to the file server 130 (as per 370, as determined by the file description data), the upload of file segments 180 from source processor 140 to file transfer server 130 could stop at 380.
It may be noted that encrypted file segments 180 can be stored at file transfer server 130, after they have been received from source computer system 110. The encrypted file segments 180 can be stored on a number of servers, such as the cloud, in an embodiment. The file transfer server 130 can perform basic storage and retrieval functions in an embodiment. The file transfer server 130 can respond to requests from the source system 110 about the existence or absence of file segments 180. This is used, for example, to determine if file segment 180 is on file transfer server 130. An embodiment may hide from the file transfer service 130 the identity of encrypted file segments 180 by using file description data. An embodiment may reveal the number of file segment 180 in the file 160 being transmitted. However, an attacker may not be able to access the file transfer servers 130 to determine which file segments 180 are required to create the file copy 200. In an equivalent fashion, the metadata from the file server 130 that identify the name, mime type and/or size file 160 may be encrypted within the file description data. This prevents attackers or insiders from accessing the file server 130 to know such data. You may appreciate that users can choose whether to upload data such name, size and Mime type as encrypted or unencrypted in certain embodiments.
“In one embodiment, the file 160 may be transferred from the source computer 110 to the recipient system 120 with the recipient system 120 receiving encrypted file segments 180 from server 130. You may realize that there are many ways to receive file segments 180. In one embodiment, the file server 130 could notify the recipient computer 120 that new file segments 180 have been made available. This notification would be associated with a workspace to the 120 subscribers. The recipient computer system 120 could poll the file transfer server 130 to determine if an update to the file 160 is available. An embodiment may allow the recipient computer system 120 to transfer the file 160 automatically based on the transfer from source computer system 110. In an embodiment, for example, the file transfer server 130 could prompt the recipient computer 120 to start receiving file segments 180 as soon as they are transmitted from the source computer 110. One or more file segments 180 may be transferred by the source computer system 110 directly to the recipient system 130. This bypasses the file transfer server 130. In an embodiment, the file transfer functionality 130 of the file server 130 can be provided by one or both the source computer system 110 or the recipient computer system 120 to facilitate the transfer of the file 160.
“As such, the software client190 running on the recipient’s computer processor 150 at the receiver computer system 120 could be configured to perform a 390 decrypting and combing the encrypted file segments 180 thereat as illustrated in FIG. 3. An embodiment of the method 390 can begin at 400 and continue at 405 with the software client190 downloading the file description data generated by 330 and uploaded to file transfer server 130 at 350 in method 210. The file description data may be received by the software client 190 at 420. After that, the workspace key can be used to decrypt the information about file segments 180 collected by the source computer 110 at 320 in method 210.
Method 390 can continue with retrieving file segments 180 after decrypting the information about file segments 180. At 430, retrieval can include determining whether a particular segment 180 is present at the recipient system 120. Segment level deduplication may include determining whether certain file segments 180 or software client 190 are available at the recipient computer 120. In this case, it would not be necessary to re-download them. One embodiment of the method for determining whether the file segment 180 is at the recipient system 120 at 430 involves comparing the file segment identifier from the file description data with information about the file segments 180 at the recipient system 120. The file segment identifier could identify, for example, one or more of the file names of the file segments 180, 180 and 180 respectively. It may also include the encrypted hash of file segment 180 or 180. An embodiment may use the file segment ID to uniquely identify file segment 180 within the system (e.g. in the file transfer server 130). File segment identifiers in an embodiment may be quite long (e.g. 256 bits) to avoid duplicate file segment identifications. An embodiment may generate file segment identifies using the SHA256 algorithm. It may also use information about file segments 180, such as the hash of unencrypted file segments 180 and 180, as inputs.
“If the file section 180 is not available on the recipient computer system 120 then the method 390 can continue at 440 by downloading segment 180. The file segment 180 can be downloaded from the file transfer server 130. However, an embodiment of the file may be downloaded from the source computer 110, the cloud or another designated storage location. File segments 180 can be stored in a local storage cache at recipient computer system 120 or another storage location that is associated with recipient computer system 120. After the file segments 180 have been downloaded at 440 or if the file segment 180 is not already available at the recipient system 120 at 430, method 390 can continue at 450 to verify the hash of encrypted file segment 180. This may confirm that file segment 180 was downloaded correctly. The steps of downloading encrypted file segment 180 and verifying their hashs can continue until all encrypted segments 180 have been processed.
The method 390 can enter into a loop to process each encrypted file segment 180 once all file segments 180 have been received at the recipient computer system 120. As shown at 470 each file segment 180 can be decrypted using the key associated to the file segment 180 stored in encrypted file description data at 410, and decrypted by 420. Method 390 can continue at 475 to decompress the file segment 180, where the file section 180 was compressed before encryption (e.g. at 270 in method 215). The file description data may include the compression algorithm that was used to compress the file segment 180 and then decompress it. Method 390 can continue at 480 after the file segment 180 has been decrypted and decompressed, if necessary, by verifying that the unencrypted segment 180 has been properly decrypted. This is done by verifying that the hash of unencrypted segment 180 as stored in the file data. A new hash can be calculated for the file section 180 after it has been decrypted and then compared to the hash generated at the source computer 110 prior to encryption of file segment 180.
It may be noted that method 390 can continue processing all file segments 180 up to a complete set 180 of unencrypted files at the recipient computer 120 as determined at 490. Method 390 can then be continued at 500 by combining the decrypted files segments 180 into the reconstructed copy 200 at recipient computer system 120. An embodiment may determine the order of reconstruction at 500 by looking at the file description data. This may include an index number for each segment 180.
Method 390 can continue at 510 after the file copy 200 has been recreated. This involves verifying the file haveh 200 and comparing it with the original 160. (The hash of original file 160 is transferred in the file data). A cryptographic hash that was generated for the file 160 may be collected by the software client 170 on the source processor 140. This will verify that the file copy 200 was received correctly and reassembled at the recipient processor 150. The cryptographic hash can then be compared with the hash from the original file 160. Method 390 can be completed at 520 after verifying that the original 160 file on the source computer 110 has been reconstructed into the file copy 200 on recipient computer 120. This could include making the file copy 200 accessible to the user of recipient computer 120.
“As mentioned above, the software client 170 may understand different versions of files 160 to transfer file segments 180 that correspond with portions of files 160 that pertain to updated data. You may also notice that the software client 170, and/or file transfer server 130 may interpret different versions of files in order to allow for tracking updates to individual files 160. A user can retrieve a list that includes all versions of a file within a workspace in an embodiment. This could include one that has been uploaded to the file server 130 or shared between the source computer 110 and the destination computer 120. An embodiment may contain version information for a file 160, such as the file’s size, modification date and uploading user. A recipient user can request older versions of file 160 to be reconstructed as file copy 200. A user can select older versions of file 160 to be removed from their workspace.
“In one embodiment, files 160 may be shared in different versions. They could have different tags. A system tag, which may include information about where the file 160 came from or details related to data loss prevention (?DLP?) may be generated by the software clients 170. An embodiment may allow users to add user tags to a file 160 after the file has been modified by the original user. These user tags can be automatically propagated to subsequent versions of the file in an embodiment. An embodiment may make user tags public so that everyone with access to the workspace can see and modify them. These tags could include, for instance, “Proposal”,? ?For Review,? ?Final? In some embodiments. An embodiment may have user tags that are private and only visible by and/or modifiable to the user who applied the tag. An embodiment may have the originating user (e.g. the owner) as the tag’s author. The file’s owner may use tags to make the file visible to others, but not modifyable by them.
“It is possible to appreciate that some of the processes associated each of the source process 140 and the recipient processing 150 may occur at most partially in the memory/cache associated with the source or recipient processor 140, respectively, in certain embodiments. The file segments 180 generated from the file 160 may be temporarily stored in the memory or cache of the source processor 140, until they are transferred. The file segments 180 may be received by the recipient processor 150. They can then be temporarily stored in the memory or cache associated to the receiver processor 150 until they are recombined into a file copy 200.
“Those who are skilled in the art will recognize that the embodiments described herein may be implemented using a server or computer, database or communications technology. Each of these technologies implements hardware and software, or a combination thereof. The embodiments of this disclosure can be implemented as a computer program product on any computer-readable medium. This medium may include hard disks, CDROM, RAM and ROM.
“For example, FIG. FIG. 4 shows a block diagram showing a high-level block diagram of an exemplary computer 530 that may be used for various embodiments of the disclosed processes, including, but not limited, processes 210 and 390 and data storage and retrieval functions at the file transfer server 130. In some embodiments, the system that performs the processes described herein may contain all or part of the computer system 533. The computer system 530 can be linked to other computer systems 530 or associated with them in some embodiments (e.g. the source computer system 110, and/or the receiver computer system 120), via a network interface (not illustrated). The computer system 530 is enclosed in a case that houses a mainboard 540. The mainboard has a system bus 560, connection ports 560 and a processing unit (CPU) 570. A data storage device such as main memory 580 or storage drive 590 and optical drive 600 is also included. The computer system 530 may be used as the source computers system 110 and the recipient computers system 120 respectively. However, the CPU570 could serve as the source processor 140 or 150 for the recipient computer processor 150. Each of the main memory 580 and storage drive 590 as well as optical drive 600 can be constructed in any configuration. Storage drive 590, for example, may be a spinning hard drive drive or a solid-state drive. Also, optical drive 600 could include a CD drive or a DVD drive.
“Memory Bus 610 couples main memory 580 and CPU 570. The system bus550 couples storage drive 590 and optical drive 600. It also connects to connection ports 560 through CPU 570. Multiple input devices can be provided, including a mouse 620 or keyboard 630. Multiple output devices can also be provided, including a printer (not illustrated) and a video monitor 644. These output devices can be configured in an embodiment to display information about the processes described herein. This includes, but is not limited to, a graphical user interface that facilitates file transfers. You may appreciate that input and output devices can be either local to the computer 530 or remotely located (e.g., by interfacing with the computer 530 via a network or another remote connection).
Computer system 530 could be commercially available or proprietary. The computer system 530 can be a desktop unit and may be supplied by any computer system provider. Computer system 530 may be a networked computer network, in which memory storage components, such as storage drive 590 and additional CPUs 570, as well as output devices, such as printers, are provided by physically distinct computer systems that are connected to each other through the network (e.g. via portions of the networked 100). The physical components and interconnections of computer system 530 will be understood and appreciated by those skilled in the art. They can then choose a computer system that is suitable for the purposes disclosed herein.
“When computer system number 530 is activated,” preferably an operating systems 650 will load into main storage 580 during the boot sequence and prepare the computer system number 530 for operation. The simplest and most basic level of an operating system’s tasks can be divided into three categories: process management, device management (including user interface management), and memory management.
“In such a computer systems 530, the CPU570 can perform one or more of the methods, platforms, components, and modules described herein. Computer system 530 may have a computer-readable media 660 on which is stored a computer program 670 to perform the methods described herein. Computer system 530 is compatible with the format of the medium 670 and the language of program 670. The operable CPU570 can read instructions from the computer program 670, and will operate according to the disclosed methods.
“Accordingly, the CPU570 may be used in combination with other CPUs 570 to perform file encryption and segmentation, and/or the file segment recombination processes described in this invention (e.g. Methods 210 and 390. The CPU 570 can be configured to execute one to several computer program modules. Each module may be programmed to perform one or many functions of the systems described. One or more of the computer programs modules could be programmed to transmit, which can be viewed on an electronic monitor such as the video monitor (640) communicatively linked to the CPU 570, a graphic user interface (which can be interacted using the keyboard 630 and mouse 620). The graphical user interface can be used to receive user input data and allow for electronic file sharing between the source computer system 110, recipient computer system 120, as well as the file transfer server 130.
“FIG. FIG. 5A and FIG. FIG. 5A and FIG. 5B show an example of a bidirectional data transformation accelerator that can harden the security, confidentiality and privacy of files in transit within an exemplary platform. FIG. FIG. 6A and FIG. FIG. 6A and FIG. 6B show a method to harden the security, confidentiality and privacy of files. It involves mapping the digital value of the original file to the digital value of the second computer system, and then transferring the obfuscated file digital values to a second system. The second system can then use the obfuscated file digital values as input for a search, query or other reference to the first system. FIG. FIG. 7 shows an additional, non-limiting embodiment.”
“Preferred embodiments of this invention have been described and shown herein. However, it will be apparent to those skilled in art that these embodiments are only examples. The invention is open to many modifications, changes, and substitutions. In practicing the invention, there may be other embodiments than those described herein. The scope of the invention is defined by the claims below. Methods and structures that fall within these claims, and any equivalents thereof, are covered.
“Example Aspects?” File Segmentation (Triple Encryption), Obfuscation and File Segmentation.
The software and system running on the origin computing node (commonly referred to as the client), perform the operations listed herein in order for a file to be segmented, triple encrypted, and obfuscated. Segments are encrypted with randomly generated AES encryption keys. Initialization vectors are used to initialize the segments. Data masking can be used to hide their contents for extra security. File Description XML The file fields are encrypted with Workspace or Transfer Keys. These keys are shared with all users who need access to the file. When a member is invited to join a workspace, their Workspace Keys will be encrypted using the Public Key.
“In this example, it is indicated to be secure that a file be transferred. The user has the option of selecting the file from a dialog box, or dragging it onto the application window. In response to an alternative input, the user has the option to choose the file that will be automatically selected by the system. The file metadata will be collected after this indication. The file metadata includes name, last modification date and size. It also contains the cryptographic hash.
“The file payload can then be broken down into segments. The segments in the current example are the same size. It is not necessary that they be the same size. The user has the option to assign file segments randomly. You can also choose to store the segments as subsets in different locations. This dispersion provides additional security hardening. You can also redistribute the contents of segments to allow for shuffling among segments. You could distribute each ith set of segments, for example.
The unencrypted metadata of the segment is then collected. These metadata can include size and cryptographic hash (including the hashing algorithm). A supported compression algorithm is used to compress the unencrypted portion. The unencrypted data file description is shown in the following example:
”
\n
“A unique AES Segment encryption key and an initialization vector are created. You can use 128-bit keys, but you can also use longer keys if all clients support them. Other algorithms can also be used, provided that all clients support them. The algorithm 3DES is used in the example.
“The compressed, unencrypted segment is encrypted with the segment encryption key. To ensure that the segment is secure from repeated data, encryption is done using Cipher Block Chaining mode. The encrypted metadata of the segment is collected. The metadata may include size and cryptographic haveh (including the hashing algorithm chosen). The encrypted file description data in the following example is:
”
\n
“The segment metadata has been collected. The metadata includes: segment ID, position of the segment in the file, clear text size and clear text haveh, cleartext hash algorithm. Compression algorithm, segment key, segment initialization vector. Seg encryption algorithm. Seg encryption mode. Seg encryption padding mode. Cipher text size. Cipher text hash.
“The previous steps are repeated for each section.”
The file and segment metadata are then used to create the File Description XML document. For the user’s convenience, some metadata fields such as hashes with their associated hash algorithm are combined. The File Description XML Document’s sensitive fields are encrypted with the shared key that is associated with file transfer. This shared key could be either the workspace key for the workspace to which the file is being added, or a random transfer key that is stored with the command to which the file is being transmitted. Except for the segment index and the segment metadata fields themselves, all of them are encrypted. The Encrypted file description XML document is sent to the server. Each segment is uploaded on the server.”
“FIG. “FIG. FIG. 1A and FIG. FIG. 1A contains a file transfer service. FIG. FIG. 1B doesn’t include a file transfer server to transfer a file from the source computer system to the recipient computer system.”
Click here to view the patent on Google Patents.