I'm building an application and want it to securely transfer data to a server.
Thinking to use public/private keys for initial handshake to encrypt a key with which to encrypt subsequent data.
Is it reasonable to have the private key integrated in the executable which will be distributed out in the wild for anyone to reverse-engineer?
I also thought of using three-pass protocol, but read about some of its weaknesses and it probably won't work for me
I followed Martin's advice and posted to security exchange (https://security.stackexchange.com/questions/158650/distribute-private-key-with-application).
There I received an answer that I accepted, by user Serverfrog:
Generate the Private/Public Keypair on the client, encrypt this with a
password (maybe choose from the User itself).
The send the Public Key encrypted via Server Public Key to the Server
and you have your entire Public/Private Stack.
Related
I have a general question about the right handling of sensitive data.
Use case scenario
A user sends sensitive data (documents or images) via an API to a Node.js server. The server then stores the data on the IPFS.
Currently the server is used in order to encrypt and decrypt the data, so that the plain text isnt stored and available on the IPFS. For encryption I am using a combination of AES and RSA similar to this example.
Questions
Would encryption with AES alone be sufficient, since hybrid encryption of AES and RSA is not really used in this case?
Should I add an additional layer of security between the client and the server (hybrid encryption, session key ...) or is a standard HTTPS connection sufficient in this case?
Any other tips or best practices I should consider? (I am not an security expert)
EDIT
Requirements and important points
The application is supposed to create licenses for uploaded Content. For this reason, the uploaded content should be secure and accessible only to authorized persons.
A person is authorized to view content if a corresponding license is available (can be queried by the system).
User experience and simplicity is important aswell
So I think a proper balance of security and usability would be ideal. Complexity or financial costs don't matter at first.
In principle, a user should not have to possess a private key. Therefore, I thought that hybrid encryption might be appropriate if an HTTPS connection is not "secure enough". My understanding would be that the server has a private and public key. When the client connects, the server tells the client the public key. Then the client generates a key for symmetric encryption (e.g. AES) and encrypts it with the server's public key. In this way, the key can be decrypted by the server and both parties have the AES key. This key can then be used to send encrypted content to the server and decrypt it there. The decrypted content can then be re-encrypted and stored on the IPFS.
Thanks in advance.
I'm wondering how I can guarantee that messages received by the server are definitely from a client that is running my app on their smartphone.
Messages sent by clients running my app will be secured by SSL encryption, so would a good solution be to include some sort of secret key that is stored on the device and on the server, that is then embedded within the message body? (but then this key is prone to being discovered through reverse engineering)
Well, no, if you cannot trust your code and if you do not have access to some kind of protected key store (that performs it's own encryption, e.g. a TPM or suchlike) then anybody can steal the key. If you require authentication you can of course use the normal authentication methods such as user passwords.
If you require the messages to be protected you can then derive a key from the password (using a PBKDF such as PBKDF2 for instance), decrypt a private key with it and use it to sign the messages. If that's too slow, you can use the private key to encrypt a session key, and use a message authentication code.
I am reading SSL security logic articles. I am confused a bit. Server has private key and server sends client public key. An encrypted data with public key only can be decrypted by private key.
1- Client side has not a private key. How does client solve the server data?
2- if public key sending over internet, somebody can Access the key who listened the network.
3- encrypt and decrypt should have an algorithm. Do all browsers knows that algorithm? if browser companies knows that encrypt algorithm, this is a security problem.
The public and private keys aren't used for data encryption in SSL. They are only used in the authentication phase. That's why the client doesn't need a private key, unless the server requires client authentication. The actual encryption is done via symmetric encryption using a negotiated session key.
There are resources on the Internet that state otherwise, notoriously the Linux Documentation Project page. They are wrong. The normative reference is RFC 2246.
Your remark about knowing the encryption algorithm is quite incorrect. First, the client has to know the algorithm to be able to encrypt and decrypt. Second, it was established many years ago that security-by-obscurity simply does not work. True cryptographic security comes from well-designed and well-tested algorithms, however well-known they may be, and key length.
I am trying to understand how SSH authorization method work because I am trying to setup an git server using gitolite.
As far as I know gitolite will use the ssh to authorize users and give access to them to a specific repository with personal write and read permissions. But I am confused about how the authorization will work.
I've watched some videos in YouTube and they use some analogy with colors to explain. If I understand right, for two persons that are going to communicate between each other in a secret way, they need a secret and public key.
The two persons know each other public keys, and to communicate between each other they agree to use one public key. To establish a connection they encrypt they private key using the same public key and send the result to each other. When they receive the result they add the private key to that message and like magic they got the same message.
But I don't think I understand this right because I can't see how the server will verify the the client. I know the server had to hold the public keys from the clients that will connect to him, but he also got a private key?
When the client tries to connect to a server, he sends his private key encrypted with his public key, and the server encrypt his private key using the client public key and send to the client?
How the server check if the user is really him? I also read that to decrypt the information encrypted with a public key, only the person that holds the private key can decrypt the message. So how the server can decrypt the message send by the client if he don't have the client private key?
If someone could explain me how the authentication, authorization, and exchange of information work using this public and private keys I would be very happy.
SSH works roughly like the following. Note that this is merely a high level explanation:
Each party has two keys: a public key and a private key. The public/private keys are related mathematically, such that they are functionally inverse. Thus an operation performed by one can only be undone exactly by the other. It is complex, but think of it like calculating x^nnn versus the nnnth root of x. The former is easy but the latter is difficult, making it computationally unfeasible to guess with enough accuracy to undo the operation. This gives us some desirable attributes that allow SSH to do the following with them:
The client connects to the server. The server proves its identity by presenting a certificate signed with its private key. The client uses the server's public key to decrypt the certificate and knows that only the client could have encrypted it since it requires the private key. The server then does the same with a certificate presented by the client. Identification can only be performed with 100% assurance using a trusted third party to manage the public keys. Without the third party only identity changes can be detected.
Now that identities are verified, the server generates a symmetric secret key, encrypts it with the client's public key, and send it to the client (who is the only one that can decrypt the message since it requires the private key). From this point on, both the client and server have the symmetric secret key, and all communication is encrypted with this key. This is done for performance reasons because symmetric encryption operations are roughly 100 times faster than asymmetric operations.
This is how SSL verifies identities, and encrypts the information. Note that more granular access control are provided by higher level applications (such as *nix file permissions), not SSL.
Explanation of this subject is a little bit excessive for Stackoverflow format.
Few days ago Coursera started a free course on Cryptography (part I) that explains exactly the matters you are interested in.
I welcome you to cryptography course to find the answers for your questions
I'm currently developing a system to transmit data between client and server, and was wondering what the strength of the encryption I planned to use was.
My thought was to have a private/public RSA key pair and hand out the public key to each client (leaving the private key solely on the server). Each client would then generate their own AES key and RSA encrypt it. They would then AES encrypt their data and send the encrypted data and encrypted AES key to the server. The server would then decrypt the AES key using the private key, and then decrypt the data using the AES key.
Are there any security flaws I am missing and/or is there a better way to do this?
This is almost exactly how SSL/TLS works (check out the handshake section). The only thing to make it stronger is to generate the AES key for each connection, rather than using the same key each time. You might also want to digitally sign messages that go back and forth to avoid man-in-the-middle and other spoofing attacks.
Generally speaking, creating a good cryptosystem is very difficult. When possible, you should always favor an existing (trusted) application to help out. In this case, you might consider sending your messages using HTTPS, rather than creating your own system.
You should give us more information about the language and platform you are using, so that we can give you specific recommendations about libraries that already exist and wich will handle the details for you. Using cryptographic primitives directly is not trivial and difficult to get exactly right, and with cryptography, you have to be "not exactly right" only once for your security to be broken.
To answer your question, it's generally a better idea to create a session secret (the AES key) through a Diffie-Hellman exchange, and each side use its private RSA key to sign its key-exchange data.
Otherwise, if the session secret is not established through a DH exchange, an adversary that gains access to the private RSA key (which has to be stored somewhere) could decrypt all traffic that was ever sent between the client and server.
If the secret is established through a DH exchange, then only the authentication part of the protocol would be exposed. Although an adversary in possession of the private RSA key would then not be able to read any previous communication, he still could either enter an authenticated dialog with the client/server or launch a man-in-the-middle attack (which may or may not be easily done, depending on the network).
One vulnerability would be if an attacker substituted their public key for the "real" public key. Then they would be able to intercept traffic as a "man-in-the-middle."
Protocols like S/MIME, PGP, and TLS use RSA encryption to transport keys just as you propose. However, the public keys they use are in certificates signed by trusted authorities.
The integrity of these trusted authorities must be carefully protected. For example, they might be burned into a tamper-proof hardware token, or a MAC might be computed over them using a password.
I'm not sure your approach will protect anything! You're going to keep the private key on the server and the public key will be distributed. If I get a hold of your public key, I'll be able to interact with your server at will. I think you should reverse the key ownership; each client will hold it's-own private key and the server will have a list of public keys (ala SSH). The server will have to add 'authorized' public keys and only to holders of the private keys will be able to connect.
Hope this helps.