Patent Application
20220385453
The disclosed teachings generally relate to data encryption and/or decryption. The disclosed teachings more particularly relate to transferring encrypted files to a third party to read without decrypting the encrypted file before transfer.
In order for a third party to read an encrypted file, the encrypted file must either be decrypted before transfer or the third party provided with a decryption key, either of which provides opportunities for bad actors to access the encrypted file.
A method for secure file transmission comprises: encrypting a file using a location key system having multi-part keys; generating an identification for the encrypted file; transmitting the identification from a sender to a recipient; transmitting a public key from the recipient to the sender; generating, by M of N devices of a set of devices associated with the sender, its respective partial secret for the encrypted file and encrypting respective partial shared secrets with the public key; transmitting, by the sender, the encrypted file and encrypted partial shared secrets to the recipient; decrypting, by the recipient, the received encrypted partial shared secrets; combining the decrypted partial shared secrets with a threshold scheme; and decrypting the encrypted file using the combined secrets.
A non-transitory computer readable medium has stored thereon instructions to cause at least one processor to execute the method. A system includes the medium and at least one processor that executes the method.
This Summary is provided to introduce a selection of concepts in a simplified form that is further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the embodied subject matter, nor is it intended to be used to limit the scope of the embodied subject matter. Other aspects of the disclosed embodiments will be apparent from the accompanying Figures and Detailed Description.
One or more embodiments of the present invention are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements.
The embodiments set forth below represent the necessary information to enable those skilled in the art to practice the embodiments, and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts that are not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure and the accompanying claims.
The purpose of terminology used herein is only for describing embodiments and is not intended to limit the scope of the disclosure. Where context permits, words using the singular or plural form may also include the plural or singular form, respectively.
Terms such as “processing,” “computing,” “calculating,” “determining,” “displaying,” “generating” or the like, unless specifically stated otherwise, may refer to actions and processes of a computing device that manipulates and transforms data represented as physical (electronic) quantities within the computer's memory or registers into other data similarly represented as physical quantities within the computer's memory, registers, or other such storage medium, transmission, or display devices.
The terms “connected,” “coupled,” or variants thereof, as used herein, may refer to any connection or coupling, either direct or indirect, between two or more elements. The coupling or connection between the elements can be physical, logical, or a combination thereof.
The terms “channel” or “link” contemplate a means of communicating data or information, whether wired or wireless, and may utilize digital cellular transmission standards (e.g., CDMA, W-CDMA, LTE, HSPA+). Examples include Bluetooth, Wi-Fi, Ethernet, USB, USB-C, Thunderbolt, auditory link, or visual link (e.g., QR code and camera). A message may be communicated directly between two devices or indirectly through another device (e.g., a relay device) on one or more channels/links.
The term “target data,” as used herein, may refer to data targeted for encryption. Examples of target data may include photos, documents, spreadsheets, audio files, video files, or any type of encryptable data files. Other examples include data stored in database tables, passwords, emails stored on a computer, or any data object.
The system is designed to provide key management without the necessity for centralized servers or passwords.
The system is a threshold cryptosystem (i.e., an M-of-N) enabling the management of keys requiring multiple devices, such as smartphones and computers. By using threshold cryptography, the system avoids the pitfalls of key management that uses centralized servers and passwords.
The system is a true zero trust system. Unlike many traditional zero trust systems that rely on passwords and client certificates, the system enables full separation of keys from identity and access management systems.
The system starts with the generation of multi-part threshold public keys (MPKs). Personal mobile devices can be key holders of shares (A/K/A “shards”) of threshold keys, because users will notice quickly if a mobile device is lost and will execute procedures to invalidate the lost device and onboard a substitute device. MPKs allow multiple devices to generate a public/private key pair without any single device obtaining the private key. These are generated using a Pederson's key generation with the appropriate commitments and verifications.
Other declarations in the secure storage folder 140 can include the name of the secure folder, content of the folder, hierarchy location of the folder, an MPK verification having a proof work to show that MPK was arrived at fairly.
The Profile Key is the cryptographic underpinning of a Profile. This allows a user to sign a message “as an identity” and verify that identity (via Security Words).
Declarations are the list of things that a profile signs and “declares” to be correct. These include:
Each declaration is written out as a deterministic JSON blob and signed using multipart schnorr signature which is attached to the result. These declarations are then published, to help others coordinate in verification and sharing.
The location key creation 120 creates a location key using the same set of devices. The location keys (public/private pair) are generated from 2 MPKs and the public location key is used by the file encryption 130 to encrypt an Advanced Encryption Standard (AES) key used to encrypt a file, which is then stored (e.g., in the secure folder backend 140). That is, the location key is not necessarily tied to a single user or file but instead to a single location. The location key creation also creates a corresponding private location key, that is sharded (split) among the devices identified by the profile key and used for decryption. The location key creation 120 also creates credential segments that are stored in the secure folder backend 140 with other cryptographic data including the sharded encrypted private location key. Accordingly, when a second user wish access to the files in the location, the first user can get those shards from the file and enable redistribution for the second user's profile.
In other words, when establishing a Location Key, the system simultaneously establishes one pairing curve (BLS) key used for signing and one traditional elliptic curve key (SECPK) used for encryption. The purpose in choosing two curves is that decryption must be performant, but our search system uses a pairing curve. Choosing two curves allows for both of these properties.
During the file encryption 130, the file encryption 130 generates an AES key and uses that key with AES Galois/Counter Mode (GCM) to encrypt an unencrypted file. The AES key is then encrypted with the location key for the location that the encrypted file is stored in (e.g., secure folder backend 140). The file encryption 130 uses Elliptic Curve Integrated Encryption Scheme (ECIES) or a threshold version of ECIES. In addition, the file encryption 130 generates a credential segment that contains an ePub needed for the decrypting the file. Both the credential and the encrypted file can then be stored together in a same file in the secure folder backend 140.
During decryption, as will be discussed further below in conjunction with
Accordingly, at no time does location private key come together on a single device. When decrypting a file, it reveals no information about any other file or directory in the location.
The system 100 employs a MofNop System, also known as a threshold consensus system. That is, requests must be approved by M of N devices. Cryptographically, there are only three main kinds of MofNop's: signing, decrypting, and redistributing.
In a MofNop, each device performs a partial computation, which are then combined in order to produce the final result. These partial computations are done in way such that the device(s) combining the partial results gains no cryptographic information outside of what was explicitly approved. For signing and decrypting, typically only one device needs to produce the final result—either a signature or a decryption.
In the system 100, files are encrypted for a location key rather than another user's profile directly. The location key can be “redistributed” to other profiles which will give them access to the location key, i.e., profiles can be added to a Security Group. Once added, these profiles can unlock files that are encrypted with that LK by decrypting the AES key used to encrypt a file.
During the file encryption 130, the file encryption 130 generates an AES key and uses that key with AES Galois/Counter Mode (GCM) to encrypt an unencrypted file. The AES key is then encrypted with the location key for the location that the encrypted file is stored in (e.g., secure folder backend 140). The file encryption 130 uses Elliptic Curve Integrated Encryption Scheme (ECIES) or a threshold version of ECIES, as will be discussed further below. In addition, the file encryption 130 generates a credential segment that contains an ePub needed for the decrypting the file. Both the credential and the encrypted file can then be stored together in a same file in the secure folder backend 140.
A “backend storage path” (often referred to as BEDS) is the location where the encrypted files are actually stored on disk. Backend locations can include cloud storage locations.
A “vault” path is the authenticated partial path of a file relative to the mount point on disk where secured files are accessed. Although in-place decryption of files is possible, it is discouraged for security reasons. Instead files are accessed using a virtual file system and are never resident decrypted on disk.
The Share DB is where the system 100 stores system files for use in a Secure Folder. Specifically, declarations are written out to the “share db”. This is a public, non-secured location where all users in a share can access (read) the data. If a share db is deleted, corrupted, invalid, or missing, a user's device simply recreates it as needed.
Authenticated metadata is information about an encrypted file, such as its path in the Vault, which issued to identify it. This data can be stored within the encrypted files of
The system 100 individually encrypts files, meaning that if a user decrypts a file, just that file's contents are exposed and not those of any other files. This is referred to as “security for data at rest.” The user chooses which data is meant to be “in use” by opening the file and approving the request, and all other data remains protected.
In order for this to be a meaningful choice, the user must be able to identify which file is actually being decrypted. Otherwise, if the user would only be tapping to decrypt a file but not necessarily the file they intended to decrypt, which could easily be exploited in an attack scenario. This identifying information is referred to as metadata.
Metadata is displayed during any sensitive file operation such as a decryption request. For encrypted files, this will describe the path of the file as known to the user, but it can also contain additional information, like the type of object in question.
When a workstation starts a creds (decryption) request for a file, it could simply send the file path to the phone alongside the request. This would appear to satisfy our needs, but offers no actual protection. Consider two attack scenarios:
First, suppose the workstation itself is completely compromised (as we must when considering multi-factor security). When the user goes to open recipes.docx, the compromised workstation switches the decryption credentials to nukes.xlsx under the hood, but sends the string “recipes.docx” to the phone. The user will think that they are decrypting the correct file based on the display, but will in fact be decrypting the attacker-chosen file.
Second, even if the workstation is not compromised, access to the underlying data storage (e.g. network share) may be. The attacker could simply swap recipes.docx.kama and nukes.xlsx.kama. To the workstation and the phone, it will appear we are decrypting the correct file when, again, the other is decrypted.
Accordingly, for metadata to be useful, it must be cryptographically authenticated so that swaps like these are impossible.
Security guarantees
Given:
The system 100 should ensure:
Note that while Epriv is never reconstituted after creation, the system 100 can support “single-device renames” (not requiring a mofnop) given access to the decryption key, since you can simply create a new ephemeral keypair in that case.
Practically speaking, this means that valid authenticated metadata can be created three ways:
[1.a.] By creating a new file with a new encryption key, in which case you have no one to fool but yourself.
[1.a.] By having access to the encryption key (e.g. after a decryption mofnop) and creating a new keypair—this is a cached-key rename. If you already have the key, you have no reason to “fake” the metadata.
[1.b.] By having access to a threshold number of devices and doing a rename mofnop. If you have the ability to do a mofnop, you may as well just decrypt the file.
For metadata in the filesystem, the system 100 starts at the root of a given bed (“storage location,” “security container”) which is directly associated with the Location Key (LK) that encrypts the files therein. The LK is treated like a “special object” at the top of the hierarchy. Below it are files and directories, which are both “normal objects,” meaning that they have ephemeral key pairs. Note: this describes the system 100 as used with files, but can also easily apply to any other hierarchical data store (or even a flat one).
Each normal object has metadata with one or more of these fields:
The location key has its own metadata defined by the lk_meta declaration, which gives it a name. Practically, this will be the path to the bed in the virtual file system.
An LK is really comprised of 2 MPKs in separate EC curves (in current implementation):
When initially creating the object, the system 100 has ephemeral keypairs for both curves and signs the metadata with each of them. This allows the system 100 to validate metadata in the context of a cryptographic operation on either curve. For example, in a creds request we care about the secp256k1 signature, but in search (if a search request displayed file metadata) we would want to validate the bls12_381 signature.
When a file is mofnop-renamed, the ephemeral key signatures are discarded in favor of the one created by the bls12_381 group key. In this case, the signature data must include the ephemeral public keys on both curves in order to establish explicit linkage with the cryptographic material.
When a Secure Folder (SF) is initially created, a special set of credentials is stored at the root of that SF. Child credentials in the SF will point to those root credentials—and so on, with sub-folders—to create a hierarchy. The root credentials are signed by a profile in a sf_meta declaration when it creates or joins the SF. This allows each profile to have its own name for the SF, while the root creds are shared.
The sharing DB 510 includes for each profile, signed declarations signed by the profile key. For example, if two profiles (corresponding to two users and their sets of devices) have access, then two sets of declarations will be stored in the DB 510. Signing requires a plurality of declared devices (e.g., M of N devices). Declarations in the DB 510 identify the declared devices and meta data for the user (e.g., real life name). Note these declarations can be located anywhere as they are public but for ease of description are shown in the shared 510. Another declaration (now shown) can be MPK verification—a proof of work showing that the MPK was derived fairly. Other declarations may also be stored in the DB 510.
The cryptographic data, stored in a secure folder of the secure folder backend 140, includes .lk_creds 520 and .lk_signing 530, which are credential segments signed with the location key(s). Note that as the location key is a threshold key, a plurality (e.g., M of N devices) are needed to sign a credential segment. The segments include credentials signed by the secpk key and credentials signed by the BLS key of the location key. The credentials include encrypted shares (shards) of private keys of the secpk key and the BLS key, which allows for redistribution of the private keys to new user profiles, as described in U.S. patent application Ser. No. 17/060,734 filed Oct. 1, 2020 and incorporated herein by reference.
.lk_creds 520, in an example, contains 3 separate profiles P1G1, P2G1, and P3G1. That is profiles 1, 2 and 3 and group 1 of devices for each. A profile may also include a second group of devices that overlaps or is completely separately from a first group, e.g., P1G2. In this example, as there are 3 profiles, 3 users have access to this location key generated by the location key creation 120. Accordingly, instead of needing encryption credentials for each file, encryption credentials can be valid for all files within a location.
The encrypted files 540 includes an encrypted file generated by the file encryption plus a credentials segment that includes the AES symmetric key used to encrypt the file and an epub needed by the ECIES process for decryption.
Device encrypts data for a group:
The process is as follows:
Conceptually, instead of the workstation generating a shared secret and dealing it out to devices, each device generates its own share, creating an “implied” secret.
So each device generates a random number, privi.
From this they derive a public key, pubi=privi*G, where G is a generator in ECC. From the public parts, the ws can use the trapdoor function to generate the public key. This public key is the same as the one that would be derived from using Shamir's Secret Sharing (SSS) with privy.
Reconstructing the public key is mathematically the same as search. For this reason, the function kata.vsss_reconstruct_hash( ) is used to construct the public key.
This feature requires a lot of communication with large latency amongst devices. For this reason, the initial mofnop doesn't do any real work. It just gathers a list of devices who are about to create the key (and implicitly checks that the user currently has enough devices to make an mpk). All the real work happens in other messages (mpk_pubpart) outside the mofnop.
For Location Keys (LKs), each location has a public/private key pair that encrypts all the AES keys in that location and a separate public/private key pair that is primarily used for metadata operations. Every group that has access to the location is given shards that can reconstruct to the private key. (Note that the system 100 never reconstructs the private key).
Formation of the MPK Group—[Round 1-Stage 1]
An MPK group is chosen from a group of devices. The number of devices in the MPK group equals the security threshold of the original device group. This MPK group will be used to construct the multi-party key in a coordinated fashion.
Private Part Generation & Commitment Transmission—[Round 1-Stage 2]
(Each Device):
Transmission of Public and Encrypted Private Parts—[Round 2-Stage 1]
(Each Device):
Verification of Public Parts, Public Key Assembly, Credential Segment Assembly—[Round 2-Stage 2]
(Each Device):
After receiving all other devices' encrypted private parts and private part commitments, device will assemble them together as a set of credentials which we call the MPK credential segment. (Note: this is a vsss shardset as described in U.S. patent application Ser. No. 16/106,564 filed Aug. 21, 2018, which is incorporated herein by reference).
After receiving all other devices' public parts, device will verify that the commitment matches the public part. This is done by hashing the public part and checking equivalence with the commitment which was sent prior.
After verifying all of the public parts, device will assemble the full MPK public key by combining all of the public parts.
Dealing in the Other Devices—[Round 2-Stage 3]
Note this stage only applies in the case that the MPK group has fewer devices than the original device group.
The workstation will initiate a redistribution from the MPK group original device group. This redistribution is done so that all of the devices in the original group will obtain a share in the MPK. This is done by redistributing the existing MPK credentials (M=N) into the full group (M<N).
Declarations & MPK Signatures
An MPK Signature
Declarations is a term for some data signed by a profile key in a threshold manner. A declaration essentially states that the required threshold of devices for a profile have agreed to sign a piece of data together. An MPK signature.
Declarations During Profile Key Creation
Profile key declarations can be constructed during the creation of the profile as no outside information is required. The declaration parts will be transmitted between devices during the public/private part transmission phase of MPK creation.
Profile Metadata
Any set of metadata that corresponds to the profile itself and contains the profile name.
Active Group
The current group config which represents the set of devices forming the profile and contains an Active group dictionary and Security threshold.
Enterprise Configuration
This declaration is written if the workstation is onboarded with an enterprise configuration present.
Signifies the original enterprise config for this profile. This allows devices to determine whether they should accept an updated config or not and contains the enterprise configuration.
Declarations During Location Key Creation
Location key declarations are constructed after the Location Key MPK is created. This is due to the fact that the location key MPK identifier itself is used in the signature. The declaration parts will be transmitted after the creation of the location key in the finalization stage.
MPK Verification SECPK
Signifies that the profile trusts the SECPK MPK part of the location key and contains: the hash id of the secpk mpk public key; the mpk type; and the verification depth.
MPK Verification BLS
Same as SECPK
Location Key Metadata
Any set of metadata that corresponds to the location key itself such as the location key name; the hash id of the secpk mpk public key and the hash id of the bls mpk public key.
The computing device 1700 may be a standalone device or part of a distributed system that spans multiple networks, locations, machines, or combinations thereof. In some embodiments, the computing device 1700 operates as a server computer (e.g., relay server) or a client device (e.g., originating device, delegate device) in a client-server network environment, or as a peer machine in a peer-to-peer system. In some embodiments, the computing device 1700 may perform one or more steps of the disclosed embodiments in real-time, in near real-time, offline, by batch processing, or combinations thereof.
As shown, the computing device 1700 includes a bus 1702 operable to transfer data between hardware components. These components include a control 1704 (i.e., processing system), a network interface 1706, an Input/Output (I/O) system 1708, and a clock system 1710. The computing device 1700 may include other components not shown or further discussed for the sake of brevity. One having ordinary skill in the art will understand any hardware and software included but not shown in
The control 1704 includes one or more processors 1712 (e.g., central processing units (CPUs), application specific integrated circuits (ASICs), and/or field programmable gate arrays (FPGAs)) and memory 1714 (which may include software 1716). The memory 1714 may include, for example, volatile memory such as random-access memory (RAM) and/or non-volatile memory such as read-only memory (ROM). The memory 1714 can be local, remote, or distributed.
A software program (e.g., software 1716), when referred to as “implemented in a computer-readable storage medium,” includes computer-readable instructions stored in a memory (e.g., memory 1014). A processor (e.g., processor 1012) is “configured to execute a software program” when at least one value associated with the software program is stored in a register that is readable by the processor. In some embodiments, routines executed to implement the disclosed embodiments may be implemented as part of operating system (OS) software (e.g., MICROSOFT WINDOWS, LINUX) or a specific software application, component, program, object, module or sequence of instructions referred to as “computer programs.”
As such, the computer programs typically comprise one or more instructions set at various times in various memory devices of a computer (e.g., computing device 1700) and which, when read and executed by at least one processor (e.g., processor 1712), cause the computer to perform operations to execute features involving the various aspects of the disclosed embodiments. In some embodiments, a carrier containing the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a non-transitory computer-readable storage medium (e.g., memory 1714).
The network interface 1706 may include a modem or other interfaces (not shown) for coupling the computing device 1700 to other computers, for example, over the network 1724. The I/O system 1708 may operate to control various I/O devices, including peripheral devices such as a display system 1718 (e.g., a monitor or touch-sensitive display) and one or more input devices 1720 (e.g., a keyboard and/or pointing device). Other I/O devices 1722 may include, for example, a disk drive, printer, scanner, or the like. Lastly, the clock system 1710 controls a timer for use by the disclosed embodiments.
Operation of a memory device (e.g., memory 1714), such as a change in state from a binary one to a binary zero (or vice versa) may comprise a visually perceptible physical transformation. The transformation may comprise a physical transformation of an article to a different state or thing. For example, a change in state may involve accumulation and storage of charge or release of stored charge. Likewise, a change of state may comprise a physical change or transformation in magnetic orientation, or a physical change or transformation in molecular structure, such as from crystalline to amorphous or vice versa.
MPK—a threshold multi-part key
r—the per-file secret used in ECIES
R—the public key of r
LKe-priv—the private key of an MPK used for ECIES, split among multiple factors, or a single factor
LKe-pub—the public key of LKe-priv
sftid—the unique ID of a SFT
workstation—among the sender's encryption factors (set of devices N, which maybe greater than or equal to 1), the device used to initiate the SFT
file—used to denote a single unit of encrypted data, but need not necessarily be a traditional “file on disk”
Procedure
Setup: MPK Setup and File Encryption
For a given data location, MPKs must be generated and redistributed to a group of devices with a thresholded scheme. An example of this procedure is described above. In an example, the group may comprise a single device.
Files are encrypted with this MPK such as described above for each file: a shared secret is derived from r and LKe-pub, which is used to encrypt the random encryption key for the file.
A. New SFT is Created
The user selects the file(s) to be included and creates the SFT, which generates a random sftid. The sftid is packaged alongside other pertinent data, such as the workstation's public key, and encoded in a manner that can be parsed by the recipient. For example, this could take the form of a URL or QR code.
B. Recipient Accepts the SFT
The recipient parses the package containing the sftid. In order to proceed, the recipient must have some kind of public-private keypair, which will be used to encrypt sensitive data before transit. This keypair may originate in several ways, including:
The recipient sends its public key, along with the sftid, to the workstation. The recipient sees a deterministic identifier of its public key, which can be used for identify verification in C. This can include a human way to identify each other, such as words. For example, verification can include transmission via a second channel (other than that used for the SFT transmission), e.g., via an audio channel as disclosed in U.S. patent application Ser. No. 17/151,293 filed Jan. 18, 2021, which is incorporated herein by reference in its entirety.
C. Sender Encrypts Data for the Recipient
Once the sender has received the recipient's public key message, it may use said key to encrypt the secret key parts for transit. The workstations communicates a request to perform this encryption to the other devices owning a piece of LKe-priv. Note that there may be only 1 device owning all of Like-priv. Before the request is started or accepted, all devices may display the recipient's key identifier, which the user may confirm with the recipient in an external channel to prevent attacks.
If the request is accepted, each participating device computes its partial shared secret for each file (a computation of R and the device's share of LKe-priv). Each shared secret part is then encrypted for the recipient's public key and sent to the workstation for collation.
D. Sender Transmits Encrypted Data to the Recipient
The sender transmits the encrypted shared secret parts and the encrypted file to the recipient. The method of this transmission, as with the other communication described above, could take many forms, such as:
E. Recipient Decrypts the Data
Once the recipient receives all needed data, the files can be decrypted. This may be done immediately or as files are accessed. In order to decrypt a given file, the recipient decrypts each encrypted part using their private key, then combines them as per Shamir's Secret Sharing scheme. The file encrypted key is then decrypted, which in turn is used to decrypt the file contents.
The following examples describe various embodiments of methods, machine-readable media, and systems (e.g., machines, devices, or other apparatus) discussed herein.
1. A method for secure file transmission, comprising:
encrypting a file using a location key system having multi-part keys;
generating an identification for the encrypted file;
transmitting the identification from a sender to a recipient;
transmitting a public key from the recipient to the sender;
generating, by M of N devices of a set of devices associated with the sender, its respective partial secret for the encrypted file and encrypting respective partial shared secrets with the public key;
transmitting, by the sender, the encrypted file and encrypted partial shared secrets to the recipient;
decrypting, by the recipient, the received encrypted partial shared secrets;
combining the decrypted partial shared secrets with a threshold scheme; and
decrypting the encrypted file using the combined secrets.
2. The method of example 1, wherein the multipart threshold key is generated by each device of the set of devices including:
generating a private key part;
deriving a public key from the private key part;
hashing the public key part and transmitting the hash to other devices of the set of devices;
receiving hashes of the other devices public key parts;
upon receiving all expected hashes, transmitting its public key part to the other devices;
receiving public key parts from the other devices;
verifying the received hashes match the received public key parts; and
calculating a public part of the multipart threshold key.
3. The method of any of the preceding examples, wherein encrypting the file using the location key system includes deriving a shared secret from a per-file secret used in Elliptic Curve Integrated Encryption Scheme and a public location key.
4. The method of any of the preceding examples, further comprising using the shared secret to encrypt an encryption key used in the encrypting the file.
5. The method of any of the preceding examples, further comprising, verifying, by the sender, an identifier of the public key, via a channel other than the channel used for transmitting the public key.
6. The method of any of the preceding examples, wherein the verifying includes verifying, by M of N devices of the set of devices associated with the sender the identifier of the public key.
7. The method of any of the preceding examples, wherein generating the partial shared secrets includes multiplying a device's share of a private location key by a public key of a per-file secret used in Elliptic Curve Integrated Encryption Scheme.
8. The method of any of the preceding examples, wherein the threshold scheme is Shamir's Secret Sharing.
9. The method of any of the preceding examples, wherein encrypting the file comprises: creating an asymmetric profile key comprising a multipart threshold key using the set of user devices; signing a declaration using the profile key and the set of user devices, the declaration identifying the set of user devices;
creating an asymmetric location key comprising two multipart threshold keys;
sharding and storing the asymmetric location key;
creating a symmetric key;
encrypting the file with the symmetric key;
encrypting the symmetric key with the location key; and
storing the encrypted file and encrypted key such that the encrypted file cannot be decrypted without decrypting the location key by a threshold of the set of user devices.
10. A non-transitory computer-readable medium having stored thereon instructions to cause a computer system to execute a method, the method comprising:
encrypting a file using a location key system having multi-part keys;
generating an identification for the encrypted file;
transmitting the identification from a sender to a recipient;
transmitting a public key from the recipient to the sender;
generating, by M of N devices of a set of devices associated with the sender, its respective partial secret for the encrypted file and encrypting respective partial shared secrets with the public key;
transmitting, by the sender, the encrypted file and encrypted partial shared secrets to the recipient;
decrypting, by the recipient, the received encrypted partial shared secrets;
combining the decrypted partial shared secrets with a threshold scheme; and
decrypting the encrypted file using the combined secrets.
11. A computer system, comprising:
at least one processor; and
a non-transitory memory having stored thereon instructions to cause the at least one processor to execute a method, the method comprising:
encrypting a file using a location key system having multi-part keys;
generating an identification for the encrypted file;
transmitting the identification from a sender to a recipient;
transmitting a public key from the recipient to the sender;
generating, by M of N devices of a set of devices associated with the sender, its respective partial secret for the encrypted file and encrypting respective partial shared secrets with the public key;
transmitting, by the sender, the encrypted file and encrypted partial shared secrets to the recipient;
decrypting, by the recipient, the received encrypted partial shared secrets;
combining the decrypted partial shared secrets when M>1; and
decrypting the encrypted file using the combined secrets.
12. The system of any of the preceding examples, wherein the multipart threshold key is generated by each device of the set of devices including:
generating a private key part;
deriving a public key from the private key part;
hashing the public key part and transmitting the hash to other devices of the set of devices;
receiving hashes of the other devices public key parts;
upon receiving all expected hashes, transmitting its public key part to the other devices;
receiving public key parts from the other devices;
verifying the received hashes match the received public key parts; and
calculating a public part of the multipart threshold key.
13. The system of any of the preceding examples, wherein encrypting the file using the location key system includes deriving a shared secret from a per-file secret used in Elliptic Curve Integrated Encryption Scheme and a public location key.
14. The system of any of the preceding examples, further comprising using the shared secret to encrypt an encryption key used in the encrypting the file.
15. The system of any of the preceding examples, further comprising, verifying, by the sender, an identifier of the public key, via a channel other than the channel used for transmitting the public key.
16. The system of any of the preceding examples, wherein the verifying includes verifying, by M of N devices of the set of devices associated with the sender the identifier of the public key.
17. The system of any of the preceding examples, wherein generating the partial shared secrets includes multiplying a device's share of a private location key by a public key of a per-file secret used in Elliptic Curve Integrated Encryption Scheme.
18. The system of any of the preceding examples, wherein the threshold scheme is Shamir's Secret Sharing.
19. The system of any of the preceding examples, wherein encrypting the file comprises: creating an asymmetric profile key comprising a multipart threshold key using the set of user devices; signing a declaration using the profile key and the set of user devices, the declaration identifying the set of user devices;
creating an asymmetric location key comprising two multipart threshold keys;
sharding and storing the asymmetric location key;
creating a symmetric key;
encrypting the file with the symmetric key;
encrypting the symmetric key with the location key; and
storing the encrypted file and encrypted key such that the encrypted file cannot be decrypted without decrypting the location key by a threshold of the set of user devices.
20. The system of any of the preceding examples, wherein M and N are both equal to one.
Aspects of the disclosed embodiments may be described in terms of algorithms and symbolic representations of operations on data bits stored on memory. These algorithmic descriptions and symbolic representations generally include a sequence of operations leading to a desired result. The operations require physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. Customarily, and for convenience, these signals are referred to as bits, values, elements, symbols, characters, terms, numbers, or the like. These and similar terms are associated with physical quantities and are merely convenient labels applied to these quantities.
While embodiments have been described in the context of fully functioning computers, those skilled in the art will appreciate that the various embodiments are capable of being distributed as a program product in a variety of forms and that the disclosure applies equally regardless of the particular type of machine or computer-readable media used to actually effect the embodiments.
While the disclosure has been described in terms of several embodiments, those skilled in the art will recognize that the disclosure is not limited to the embodiments described herein and can be practiced with modifications and alterations within the spirit and scope of the invention. Those skilled in the art will also recognize improvements to the embodiments of the present disclosure. All such improvements are considered within the scope of the claims disclosed herein. Thus, the description is to be regarded as illustrative instead of limiting.
This application claims the benefit of U.S. provisional patent application No. 63/194,570 filed on May 28, 2021, and titled “SECURE FILE TRANSFER,” which is incorporated by reference herein in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 63194570 | May 2021 | US |
