secure-transmit is a file transmission service that allows you to transmit data of any size, from anyone you like, to anyone you like.
Electronic communications occur every day. But occasionally, you need to transmit data of some significance for a particular task. Perhaps you are transmitting your financial records to your accountant, or sensitive legal documents to your lawyer, or complicated design documents to your vendor. Transmissions are communications that have consequences, should the information being transmitted go astray or awry. They require some combination of the following attributes:
secure-transmit stores files in AWS S3, using AWS's multipart file uploader. AWS documentation claims that files up to 4TB can be uploaded.
Email limits the size of email attachments. Many providers limit attachments to less than 50MB.
Cloud Storage and Cloud Based Collaboration environments are built around the concept of a shared, cloud based disk, and as such can usually accommodate sharing large files. Maximum storage quotas for these systems are generally generous, but adjusting storage quotas for intermittent transmissions can increase the subscription cost for only intermittent benefit.
secure-transmit allows customized instructions for each correspondent, and can attach arbitrary metadata to every transmitted file.
Email provides no specific provisions for instructions, and metadata. They may or may not be included in the cover text, or separate mailings, or they may be totally omitted.
Cloud Storage and Cloud Based Collaboration environments are built around the concept of a shared, cloud based disk. They don't generally have a concept of a transmission - transmissions are accomplished by providing temporary read credentials for correspondents. Consequently, any instructions or metadata must be transmitted, if at all, in separate emails, whose association with the transmitted file(s) are tenuous at best.
secure-transmit requires multi-factor authentication for all correspondents, including you, the sponsor. Correspondents may be required to prove their identity by possession of an access URL and any combination of email address, phone number, knowledge of a shared secret, and possession of the private key paired to a supplied public key.
Email generally does not require multi-factor authentication to access an email inbox.
Cloud Storage and Cloud Based Collaboration environments generally don't require multi-factor authentication for a user to access their shared area, because users find it onerous. Transmission correspondents are generally allowed access by a token that grants temporary rights to pick up or drop off a file. Those tokens, once granted, establish the identity of a correspondent with a single factor.
secure-transmit requires the transmission sponsor to specify the lifespan of both data and metadata. This lifespan can be adjusted, but data life never extends beyond 30 days. This ensures that old transmissions don't remain, risking exposure or error. This is an important advantage of a system that considers a transmission as a well defined atomic transaction, rather than a loose assortment of messages and files.
Email does not provide an automated facility for expiring data after it has been transmitted. Sensitive data sits in a sent email folder until someone manually deletes it.
Cloud Storage and Cloud Based Collaboration environments don't expire data.
secure-transmit encrypts all data and metadata. Data is stored in AWS S3 using AWS's Server Side Encryption with Client Side Keys - a software option that encrypts the file block by block with a FIPS-2 compliant AES cipher, and requires the client to store the key for decryption. In secure-transmit, this key is added to the transmission metadata. The transmission metadata is encrypted using openssl's AES-CBC256 cipher, using a key that is a function of the correspondent's access URL and the transmission password. The encrypted metadata (containing the key to the data stored in S3) is then stored in a DynamoDB database under a key that is another function of the correspondent's access URL and the transmission password. Neither the data in S3 nor the metadata in the DynamoDB database can be decrypted without keys held only by the correspondents (the sponsors, senders and receivers of the transmission).
Email doesn't implement encryption by default. If you choose to encrypt your email locally, and your correspondents are similarly cautious and equipped, you are able to send and receive encrypted emails. But the effort, learning and infrastructure required for this level of security is difficult for any but the most diligent to maintain.
Cloud Storage and Cloud Based Collaboration tools may or may not encrypt the files in their storage areas. If they do encrypt the files at rest, generally all of the files in a user area are encrypted with a single key, and often these keys are accessible to the Cloud Storage or Cloud Based Collaboration system.
secure-transmit only requires that correspondents have an email address and a browser. No software needs to be installed for a correspondent to send and receive files. This is both a convenience and a security advantage - client side infrastructure is vulnerable and difficult to audit.
Email doesn't require anything other than an email account and a browser/email client.
Some Cloud Storage and Cloud Based Collaboration tools require client side infrastructure, either for providing access or for end-to-end encryption. This client side infrastructure both restricts the universe of correspondents to those who have gone to the effort to install it and presents a vulnerability. If the version of the client side infrastructure on your machine has an exploitable vulnerability, you have no way to know.
secure-transmit documents every contact and action by every participant in a transmission (including timestamps, checksums, and remote IP addresses), and that record in its entirety is accessible to the sponsor of the transmission. All other participants in the transmission can access a complete record of only their contacts and actions. These records are retained for a period of time the transmission sponsor can control. All of the transmission records are encrypted, and only accessible to the correspondents involved in the transmission.
Email only provides a rudimentary facility for read receipt, and even that is often not reported, depending on the policy of the email client of the correspondents.
Cloud Storage and Cloud Based Collaboration environments don't generally record any actions by the owner of the files or collaborators with long lasting access to cloud assets, because shared file systems don't generally keep records on the access patterns by authenticated users of files. Depending on the details of the particular system, they may keep records of accesses of correspondents via access tokens, but maybe not.
secure-transmit's records include MD5 and SHA256 checksums of all downloaded files. This allows everyone involved in the transmission (sponsor and receiver) to be able to prove the exact version of the file that was downloaded. When a correspondent downloads the record of the transmission, it is cryptographically signed, which ensures that the record cannot be falsified.
Email doesn't keep a record of downloads - only delivery. Checking the checksum on either end does not prove what version was downloaded - either party could have changed the file post delivery.
Cloud Storage and Cloud Based Collaboration provide the means for correspondents to copy the files to be transferred from a shared cloud storage area. Checksums aren't calculated when files are copied, so changes to the downloaded files on either end can cause differences of opinion about which version was downloaded.
secure-transmit provides optional feedback by email or text for all contacts, or all uploads, or all downloads, or notification when the files are deleted. This allows a sponsor to track which of their correspondents are participating in the transmission in real time.
Email doesn't provide any feedback other than read receipt, which is only honored by the co-operation of the receiver.
Cloud Storage and Cloud Based Collaboration tools don't distinguish which of the file accesses are associated with a transmission, so even if access records are kept, real time alerts are not given.
secure-transmit does not require a user account for either end of the transmission. A transmission is a transaction that does not require any continuing relationship with secure-transmit. No continuing subscription either.
Email is a prerequisite for essentially all digital transmission infrastructure, including secure-transmit.
Cloud Storage and Cloud Based Collaboration environments require a user account for at least one of the correspondents in a transmission, conceivably for both. And generally, those accounts come with a monthly subscription. When they don't, you should wonder what of yours is being traded for that free service.
secure-transmit can be used by an organization of any size. Charges do not scale by the size of the user community, only by the number of transmissions and the amount of data transmitted. No information about the user community need be divulged to secure-transmit, yet the organization can determine which of its users generated which charges.
Email is a prerequisite for essentially all digital transmission infrastructure, including secure-transmit.
Cloud Storage and Cloud Based Collaboration charge by the user account. If an organization has a large population of users who very occasionally need to transmit data, then Cloud Storage and Cloud Collaboration solutions can be very expensive.
You should consider secure-transmit:
secure-transmit is for securely transmitting a well defined packet (even very large in size) of data between a well defined set of correspondents, for a well defined purpose, and keeping track of what was sent from whom, to whom, and when.
When you define a transmission, you name the correspondents who will exchange data in the transmission. You will be required to define for each correspondent the proofs of their identity, including yourself. At a minimum, a correspondent must have an email address, but they can also be required to demonstrate that they control a phone number (voice or text), on which they will receive one time security codes. In addition, a correspondent can be associated with a public key, and to prove their identity they will be required to demonstrate that they possess the private key paired with their public key. Finally, a password can be attached to a transmission, and all correspondents must be able to demonstrate their knowledge of the password as a further proof of identity.
When you define a transmission, you provide proofs of identity for all correspondents, including you. secure-transmit requires that you click on a link and provide your proof(s) of identity before alerting any of your correspondents of the transmission. Your proof(s) of identity are shared with all of your correspondents, as well as the assurance that secure-transmit has verified them all (email, and optionally, phone, private key, and password). Your correspondents should recognize your proof(s) of identity, and if they do not, they can feel free to check them (by sending an email or calling a phone number), or totally disregard your transmission as being untrustworthy.
When data is uploaded for transmission, it is stored in an AWS S3 directory, encrypted with keys that are not stored by AWS. (The AWS storage mechanism is called Server Side Encryption, with Client Side Keys). The unencrypted file is never stored in the file system or memory of any server, and the decryption keys are inaccessible to secure-transmit without information held only by the correspondents. Furthermore, when the transmission is defined, you can specify a geographic region where the encrypted data will reside, which is sometimes required by various regulations. Finally, when the transmission is defined, you will be required to define a file retention period, after which the data being transmitted will be automatically deleted. If you like, by selecting the gear on the Transmission screen, you can request notification by text or email when this deletion occurs.
The metadata associated with a transmission define the proofs of identity of all correspondents, and any instructions to be shared with correspondents. In addition, all activity associated with a transmission are logged, to allow the sponsor of the transmission to know that their data was correctly received. All of this data is stored in secure-transmit's internal database, but it is stored in such a manner that it is not accessible to secure-transmit without keys held only by the correspondents. Every record in secure-transmit's internal database is encrypted with its own key. The keys are not held by secure-transmit, but instead are held by the correspondents. In the course of the transmission, when files are uploaded or downloaded by correspondents, each of these actions requires the correspondent to pass a key to secure-transmit, and secure-transmit will use this key to locate and decrypt the correct record. Only then will be metadata associated with the transmission in question be revealed to secure-transmit, so that it can perform the actions necessary to make the transmission happen. Furthermore, when the transmission is defined, a records retention period can be defined. When this period expires, all of the records associated with the transmission will be deleted. Because of the structure of secure-transmit's internal database, it is impossible for secure-transmit to know what transmissions are in flight, or to know what customers are being served at any time. Because of the requirement that every record have its own decryption key, a single decryption of a record in secure-transmit's database can reveal data about only ONE transmission. secure-transmit cannot leak a list of user account names and data, because it has no list of user accounts. In fact, secure-transmit does not have user accounts as most systems implement them.
secure-transmit doesn't require a user account, and doesn't have subscriptions, as previously mentioned. secure-transmit can be used in an entirely ad hoc manner, where the sponsor pays for each transmission individually. If a user or organization anticipates lots of transmissions, there is a flexible mechanism for allowing a bulk purchase to be used by a purchaser who can define a set of transmission sponsors.
At the moment, secure-transmit allows user to try the service for small transmissions (<10MB). Larger transmissions cost money, and a transmission cannot be initiated without payment having been arranged. It is possible to pay for a single transmission. A transmission whose total data to be transmitted is less than 1GB costs $3 USD, a transmission whose total data to be transmitted is less than 5GB costs $5 USD, and a transmission whose total data to be transmitted is less than 20GB costs $10 USD. Data is accounted when it is delivered to the recipient(s). If there are 5 recipients, each downloading 1GB, this is a 5GB transmission. If a transmission racks up downloads larger than what was paid, or if a free transmission exceeds its 10MB allotment, downloads will be suspended until the funding is increased.
If you expect to have a recurring need for transmissions, it is cheaper and easier to pay secure-transmit a lump sum which can be used to fund a large number of transmissions. This model should be thought of like charging up a transit card and using it to ride the subway a bunch of times, or paying into an EZPass account and riding the turnpike as much as you want. Each transmission debits a balance in an account, and when the money is used up, the account will stop working, or the user can pay more money into the account. Like a subway card, the account should be thought of as a token that gives access to funding, rather than a user identity.
There are two different kinds of accounts - Basic and Enhanced. You can open a Basic Account with a deposit of $35 USD. When you open the account, it will create a passphrase associated with your proof(s) of identity. When you want to fund a transmission, you provide the passphrase, and the charges associated with the transmission will be debited from the account. Only someone who can provide your proof(s) of identity can use your passphrase. A Basic Account allows you to grant the ability to use the account to two other identities. This grant is known as a User Proxy, and each of the User Proxies of a Basic Account will be associated with a single identity and will have its own passphrase. This is designed for a small office, or a family, to share access to the Basic Account.
An Enhanced Account can be opened with a deposit of $250 USD or more. Enhanced Accounts are designed for use by a mid to large organizations. To grant access to the account to many employees, the Enhanced Account is not limited in its number of proxies. Conceivably you could grant an individual User Proxy to each employee you would like to give access to the account. Alternatively, there are two different types of proxy available to the Enhanced Account to simplify management of a large group of employees. A Domain Proxy associates a passphrase with an email domain. Any person whose proofs of identity connect to a specified domain will be able to use the proxy. When you check the account records it will reference all charges against the account by proxy and by sponsor, so charges can be ascribed to the sponsor who generated them. The final kind of proxy is a Promiscuous Proxy, which has no restrictions on the sponsor who can use it. A Promiscuous Proxy can be used by anyone who knows the passphrase for the proxy.
Enhanced Accounts can also limit the use of a proxy to a specified number of transmissions, a specified maximum expenditure, or a specified lifespan. When you create a Basic or Enhanced Account you will be able to access an interface that allows you to grant or retract access through the proxies associated with the account.
The proxy mechanism allows the person who established the account to maintain their own set of authorized users without requiring any assistance from secure-transmit. The charges from secure-transmit do not scale in any way by the number of users accessing the account. Charges are based only on number of transmissions and the amount of data transmitted.