I have some issues regarding to find a way to achieve the encryption of arbitrary data that can be shared with multiple recipients. Mega seems to do exactly that. As far as I read it encrypts the data before its uploaded to the web server. Still it is possible to share that file with others. How is that done with the encryption?
Imagine the following scenario:
- User Alice uploads a file to the server, it is being encrypted
- Alice wants to share that file with Bob and Dave. How can Bob and Dave access the file and see its original content (decrypted)?
How is that done with the encryption?
The answer is symmetric-key algorithm. Mega utilizes in-browser, symmetric key encryption provided by HTML5. See question "What encryption algorithms does MEGA use internally?" below.
As onemouth said, your data glob is encrypted with a master key.
Every user also has a public/private key pair. And every file is
encrypted under different session key. Session keys are encrypted
under user's master key.
To understand how it all works means looking at all the component pieces and seeing how they interoperate. Mega explains the process of encrypting symmetric/shared keys on their website:
(embedded links and emphasized text in quoted text added by me)
What encryption algorithms does MEGA use internally?
For bulk transfers, AES-128 (we believe that the higher CPU
utilization of AES-192 and AES-256 outweighs the theoretical security
benefit, at least until the advent of quantum computers).
Post-download integrity checking is done through a chunked variation
of CCM, which is less efficient than OCB, but not encumbered by
patents.
For establishing shared secrets between users and dropping
files into your inbox, RSA-2048 (the key length was chosen as middle
grounds between "too insecure" and "too slow"). All encryption,
decryption and key generation is implemented in JavaScript, which
limits throughput to a few MB/s and causes significant CPU load. We
are looking forward to the implementation of the proposed HTML5
WebCrypto API in all major browsers, which will eliminate this
bottleneck. JavaScript's built-in random number generator is enhanced
through a mouse/keyboard timing-driven RC4 entropy pool as well as
crypto.* randomness where available (Chrome and Firefox only at the
moment - keys generated by Internet Explorer and Safari are less
secure than they could be).
How does folder sharing work?
You can share any subtree of your cloud drive with friends, family or
coworkers. Invitation is by e-mail address. Invitees who do not have
an account yet will receive an e-mail notification with a signup link.
Alternatively, you can create a public link to any of your folders and
export the folder-specific crypto key, making it accessible without a
MEGA account. It is then your responsibility to securely transmit the
folder key to the recipient(s).
To establish, modify or delete a share, simply right click on a folder
in your file manager and select Sharing. There are three access
levels: Read-only, read/write (files can be added, but not deleted),
and full (files can be added and deleted). If you added an e-mail
address that did not have an account yet, you need to be online at
least once after the recipient completes the signup process so that
you can encrypt the share secret to his newly created public key.
Is data that I put in shared folders as secure my other data?
Shared folders, by nature, are only as secure as their least secure
member.
Instead of just one master key, you now have another key that you have entrusted to X number of people. Your security is as great as your trust of those X people.
Each file on Mega has a unique ID. So if the credentials are:
fileId=Abc123Ab
shareKey=abcdefghijklmnopqrstuvwxyz0123456789ZYXWVUT
https://mega.co.nz/#!fileId!shareKey
Attempting to download
https://mega.co.nz/#!fileId
will result in downloading the encrypted file. The file cannot be decrypted unless the user has the shared decryption key. How you get the "shareKey" to someone is up to you. But anyone with access to that shareKey can decrypt the downloaded file so sending the full URL via email or other unencrypted mediums is a bad idea. Once a shareKey is generated (by "Get Link" in the webapi) it cannot be changed.
And additionally,
However, a compromise of our core server infrastructure poses
an additional risk: Public keys could be manipulated, and key requests
could be forged.
What they are saying is the security issues that arise without sharing enabled increase because the individual threats of individual private key compromise.
Is my stored data absolutely secure? All security is relative. The
following attack vectors exist - they are not specific to MEGA, but we
want you to know about the risks: Individual accounts are jeopardized
by:
- Spyware on your computer. A simple keylogger is enough, but session credentials and keys could also be extracted from memory or the
filesystem.
- Shoulder surfing. Do not type your password while someone could watch your keystrokes.
- Password brute-forcing. Use strong passwords.
- Phishing. Always confirm the security status of your connection (https://) and the correct domain name (mega.co.nz) before entering
your password. Large-scale attacks could be mounted through:
- A "man in the middle" attack. Requires issuing a valid duplicate SSL certificate in combination with DNS forging and/or attacks on our BGP
routes (a DigiNotar-style scenario).
- Gaining access to the webservers hosting https://mega.co.nz/index.html and replacing that file with a forged
version (this would not affect access through the installed app base).
Note that manipulating content on our distributed static content CDN
does not pose a security risk, as all active content loaded from
index.html is subject to verification with a cryptographic hash (think
of it as some kind of "secure boot" for websites). This type of attack
requires sending malicious code to the client and is therefore
detectable.
- Gaining access to our core server infrastructure and creating forged key requests on existing shares. This type of attack only affects data
in accounts with shared folders and is detectable on the client side
as well.
Furthermore, not all data is private and most user-identifiable information is stored unencrypted.
Is all of my personal information subject to encryption? No. Only file
data and file/folder names are encrypted. Information that we need
operational access to, such as your e-mail address, IP address, folder
structure, file ownership and payment credentials, are stored and
processed unencrypted. Please see our privacy policy for details.
More detail can be had in their API documentation at https://mega.co.nz/#doc
12.2 Cryptography
All symmetric cryptographic operations are based on AES-128. It operates in cipher block chaining mode for the file and
folder attribute blocks and in counter mode for the actual file data.
Each file and each folder node uses its own randomly generated 128 bit
key. File nodes use the same key for the attribute block and the file
data, plus a 64 bit random counter start value and a 64 bit meta MAC
to verify the file's integrity. Each user account uses a symmetric
master key to ECB-encrypt all keys of the nodes it keeps in its own
trees. This master key is stored on MEGA's servers, encrypted with a
hash derived from the user's login password. File integrity is
verified using chunked CBC-MAC. Chunk sizes start at 128 KB and
increase to 1 MB, which is a reasonable balance between space required
to store the chunk MACs and the average overhead for
integrity-checking partial reads. In addition to the symmetric key,
each user account has a 2048 bit RSA key pair to securely receive data
such as share keys or file/folder keys. Its private component is
stored encrypted with the user's symmetric master key.
12.3 Shared folders
The owner of the folder is solely responsible for managing access; shares are non-transitive (shares cannot be created
on folders in incoming shares). All participants in a shared folder
gain cryptographic access through a common share-specific key, which
is passed from the owner (theoretically, from anyone participating in
the share, but this would create a significant security risk in the
event of a compromise of the core infrastructure) to new participants
through RSA. All keys of the nodes in a shared folder, including its
root node, are encrypted to this share key. The party adding a new
node to a shared folder is responsible for supplying the appropriate
node/share-specific key. Missing node/share-specific keys can only be
supplied by the share owner.
12.4 Unauthenticated delivery
MEGA supports secure unauthenticated data delivery. Any fully
registered user can receive files or folders in their inbox through
their RSA public key.
Ultimately, you are trusting their javascript code which is verified authentic by HTTPS. Then you are trusting your javascript engine (web browser) to correctly handle the transaction. And finally you are trusting your operating system to not allow other running processes to sniff out the unencrypted private key in RAM (see https://nzkoz.github.io/MegaPWN/).
There are certainly precautions to take along the way, but it is one of the best options currently available. You can always encrypt your files before uploading to Mega with GPG to alleviate some of the issues outlined above.
In Mega, every user has a master key. Every user also has a public/private key pair. And every file is encrypted under different session key. Session keys are encrypted under user's master key.
If Alice wants to share her file with Bob, first she decrypts the file's session key using her master key, then she encrypts the session key under Bob's public key.
Now Bob can use his private key to decrypt Alice's file.
The above is just an intuitive explanation. You will find more information from Mega's api (and its source code).
