Is it safe to send a mobile client an AES Key and IV from the server to use for encrypting sensitive data? The key and IV would be sent using TLS. This key would be used for encrypting data from end to end.
Update:
My requirements have actually changed, so I don't need to do this, but the solution I came up with was actually to have the client send a public key to the server over tls. Then the server could encrypt the keys with that public key and send them back to the client.
It would be as secure as any data in TLS. It also depends on how much your client trusts this TLS, which may not have two sided authentication.
But basically sending the key this way doesn't add much to using TLS. If TLS is insecure then the AES key is insecure. If it isn't then the AES key is secure...but TLS was already secure. There might be a slight advantage if you'd use a ciphersuite that provides forward security (DHE_ or ECDHE_).
But mostly, if you send anything, you'd send a public key such as a PGP key. The person on the other hand still has to trust the sender of course (i.e. by validating the fingerprint) but if the TLS connection is insecure then leaking the public key would at least not break anything encrypted using it.
Related
From what I can tell TLS works using both symmetric and assymmetric encryption.
The assymmetric schemes are used to exchange keys but when and what symmetric schemes are used?
The asymmetric schemes are used to exchange keys
and digital-signatures.
The symmetric schemes are used to data transfer with the agreed symnetric key during the key-exchange.
This is called Hybrid cryptosystem.
Yes you are right. Asymmetric algorithms are usually slower than the symmetric algorithms. However, symmetric algorithms require a shared secret key to encrypt and decrypt messages. Therefore, TLS allows the client and the server exchange a shared secret key using the asymmetric mechanism. Without an asymmetric algorithm, there is no way the shared secret can be exchanged between the two parties in a secured way. Once both the parties have the shared secret key, all subsequent communication between the client and the server are encrypted using the symmetric algorithm which is much faster than the asymmetric algorithm.
At a very high level, the steps in establishing a TLS connection looks like this:
Client -> Requests for secured session
Server -> Sends certificate & chain certificates
Client -> Verifies certificate
Client -> Generate random key for symmetric encryption
Client -> Encrypts the generated key with the server public key and sends the encrypted value to the server
Server -> Decrypt the client sent key with its own private key
Here onwards all subsequent communications between the server and the client will be encrypted using a symmetric algorithm.
Which specific algorithm will be used is determined by the cipher suites supported by the server and the client. During the connection setup, the cipher suite to be used is determined by the client preference.
A typical cipher suite name looks like this:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Here
ECDHE - Key exchange algorithm
ECDSA - Digital Signature algorithm used for signing the key
AES_128_GCM - Block cipher and mode with 128 bit key
ECDHE stands for Elliptic Curve Diffie Hellman Ephemeral. The Elliptic variant (the first E) is used for performance, whereas the Ephemeral variant (the last E) is for forward secrecy. Forward secrecy means that if an attacker keeps recording all the communications over TLS and at a later point of time somehow gets hold of the private key, he/she cannot decrypt the past recorded communications.
ECDSA is used for authenticating (verifying the integrity of) the shared secret. ECDSA is weaker and slower than the other authentication algorithms like HMAC. Yet it is used for shared key authentication because it does not need the verifier know the secret key used to create the authentication tag. The server can very well use its private key to verify the integrity of the message.
AES_128_GCM - Once a common secret key is shared between both the parties (usually a browser and a web server), a symmetric block cipher algorithm is used to encrypt the message exchanges between the parties. In this particular case, the block cipher AES with 128 bit key and GCM authentication mode is used.
If you open a HTTPS website in a browser, you can see the cipher suite used using the browser utilities. For e,g, in Firefox you can see the details under the Security tab in the Page Info, as shown below:
I am using TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite, and I have sucessfully finished the handshake process, so i should have the correct KEYS for the server side and client side, but when i use the server write key and iv to encrypt the data and put under record layer(applicaiton type) send to client, but when i use wireshark ssl debug, i found out that wireshark didn't decrypt the application data correctly, wonder is the application data use a different key to do the encryption and decryption? Thanks
I have finally found the problem, TLS 1.0 used the last block of encrypted data as new IV to encrypt the data. its a little surprised, the encrypted data is visible on the network, so anyone capture that data can find out the IV.
I'm trying to use the Qt Cryptographic Architecture to generate public/private key pairs for nodes, and want to have a protocol in which nodes confirm that a message came from a given source (public key) by issuing a challenge to ensure they are the owners of the corresponding private key. I'm a little stuck on the actual syntax for QCA though ...
This should get me a private key, from which I can also get the public key:
QCA::KeyGenerator generator;
QCA::PrivateKey privateKey = generator.createRSA(1024);
Does QCA already have some sort of challenge protocol built in? If so, how can I use it? If not, how can I apply some of the standard cryptographic challenge protocols using these keys? I'm really just trying to demo a simple security concept - I'm not looking for anything complicated or even particularly robust.
Also, this is a side question, but since I don't need encryption, should I be opting for DSA as opposed to RSA?
There are more than one of doing that. But since all clients already have their asymmetric key pairs you may deploy two-way TLS in establishing connection.
In this scheme both client and server allow establishing connection only, if they trust certificates (public keys) of each other. This guarantees client authentication and non-repudiation.
From your side you will need to provision server certificate to all clients and all client certificates to the server. To avoid dealing with certificate authorities, certificates could be self-signed.
QCA has examples for TLS client and server.
Good morning everyone.
I've been reading (most of it here in stack overflow) about how to make a secure password authentication (hashing n times, using salt, etc) but I'm in doubt of how I'll actually implement it in my TCP client-server architecture.
I have already implemented and tested the methods I need (using jasypt digester), but my doubt is where to do the hashing and its verification.
As for what I read, a good practice is to avoid transmitting the password. In this case, the server would send the hashed password and the client would test it with the one entered by the user. After that I have to tell the server if the authentication was successful or not. Ok, this won't work becouse anyone who connect to the socket the server is reading and send a "authentication ok" will be logged on.
The other option is to send the password's has to the server. In this case I don't see any actual benefit from hashing, since the "attacker" will have to just send the same hash to authenticate.
Probably I'm not getting some details, so, can anyone give me a light on this?
The short answer to your question is definitely on the side that permanently stores the hashes of the passwords.
The long answer: hashing passwords only allows to prevent an attacker with read-only access to your passwords storage (e.g. database) from escalating to higher power levels and to prevent you knowing the actual secret password, because lots of users use same pass across multiple services (good description here and here). That is why you need to do the validation on the storage side (because otherwize, as you've mentioned, attacker would just send "validation ok" message and that's it).
However if you want to implement truly secure connection, simple passwords hashing is not enough (as you've also mentioned, attacker could sniff TCP traffic and reveal the hash). For this purpose you need to establish a secure connection, which is much harder than just hashing password (in web world a page where you enter your pass should always be served over HTTPS). The SSL/TLS should be used for this, however these protocols lie on top of TCP, so you might need another solution (in common, you need to have a trusted certificate source, need to validate the server cert, need to generate a common symmetric encryption key and then encrypt all data you send). After you've established secure encrypted connection, encrypted data is useless to sniff, the attacker would never know the hash of the password.
Can a Diffie-Hellman key exchange algorithm be used to encrypt client-server communication on a web-page in place of SSL? If it can, what are the disadvantages (i.e. why does the standard use SSL which requires a certificate authority)? My understanding is that Diffie-Hellman can be used to secretly establish a shared key which then can be use to encrypt any further communication.
The two aren't really comparable. DH is a key-exchange algorithm, nothing more and nothing less. SSL attempts to establish that the server you're connecting to is really who it says it is. To do that, it uses a certificate that can be traced back to somebody you (are supposed to be able to) trust.
DH, by itself, only keeps others from reading the transmitted data. SSL is intended to establish considerably more than that (but can use DH to keep others from reading the stream).
Just for an obvious example, using DH (by itself) a Man in the middle attack is fairly simple. If I can get you to connect to my server instead of the one you intended to, I can use DH to establish a "secure" session with you. I then connect to the server you originally intended to. Every packet I get from you, I decrypt, re-encrypt with a key I used to connect to that server, and send on to that server. I do the same with all its response packets. To you, everything looks like it came directly from the original server, and the purchase you made (for example) works just like normal. The only thing that changes is that I also store your credit card number, and when you try to fill your car with fuel the next day, the charge is declined, because in the meantime I've spent all your credit.
The authentication in SSL is at least intended to prevent that from happening. If your browser tried to connect to (for example) www.amazon.com, it should give you a warning if my SSL certificate doesn't specify that it was issued to www.amazon.com -- and a CA shouldn't issue such a certificate to anybody but Amazon.
DH, by itself, doesn't really even guarantee most of what I've said above. By itself, DH is just a way to exchange a key (or, perhaps it could be phrased as "exchange information necessary for both parties to create identical keys, without ever exchanging the key itself in the clear"). After both parties have the key, they can (and presumably will) use it to encrypt/decrypt data -- but that encryption is actually separate from DH itself.
Actually Diffie-Hellman is a part of SSL.
But one part does not replace others.
From here SSL Diffie-Hellman is used for:
This a Diffie-Hellman key exchange in
which the server's certificate
contains the Diffie-Hellman public
parameters signed by the certificate
authority (CA). That is, the
public-key certificate contains the
Diffie-Hellman public-key parameters.
The client provides its Diffie-Hellman
public key parameters either in a
certificate, if client authentication
is required, or in a key exchange
message. This method results in a
fixed secret key between two peers,
based on the Diffie-Hellman
calculation using the fixed public
keys.
You can use anonymous Diffie-Hellman key agreement with SSL. This provides privacy on the channel, but no authentication.
Of course, without authentication, you really can't have privacy, because your private channel could be connected to a "man-in-the-middle". That's why the anonymous DH cipher suites are discouraged.
If the lack of a certificate is stopping you from using SSL where it's really needed, get a free one from startcom.org.
Diffie-Hellman key exchange is only for keyexchange. It does not give you authenticitation (who you're talking to), you need certificates and a PKI for that.
So yes you can do encryption, but you dont know with who you're talking to
The DH key exchange cannot, of itself, do encryption. It is used to establish a session key, but not to do the encryption. So, at this level, the question is mis-stated or reveals either lack of precision or lack of understanding (I suspect precision is the problem this time).
The question is:
Do you want to encrypt data with anybody at all?
Do you want to be sure who you are talking to?
As already pointed out, SSL uses a DH key exchange to establish a session key. However, it also ensures that the program on the other end is someone you trust (directly or indirectly). If you don't need to worry about whether the other person is trustworthy, you could just use a simple DH key exchange and then send encrypted data without needing certificates. But you won't be sure who you are talking to unless you validate that - and the certificates used by SSL etc helps with that validation.