I'm trying to figure out the most data-use efficient way to secure our CoAP API. DTLS seems to be the right way to do it, but looking at how much data the handshake requires (and making some uninformed assumptions about how often that needs to happen) it seems that DTLS with X.509 certificates dwarfs the actual data use of CoAP itself.
The most obvious solution would be to just use symmetric keys that are programmed in at the factory, but I don't think I like the security risks that imposes. As far as I understand there is no way to recover from a server-side intrusion other than manually installing new keys on all the devices.
The solution that I'm thinking of proposing is basically a hybrid of the two, distribute the devices with a secured CA that lets the devices do a standard handshake and establish a "temporary" symmetric key. Then to save bandwidth to the device I'd store that key (session?) in a database for the device to continue for months or years at a time, but still have the ability to expire the keys if we discover any have gotten out.
I know I could just use the standard session resumption handshake to resume a session, but I'm not sure that is required since DTLS is connection-less and I can pretend the "connection" is always open. And if I can avoid having to repeat the handshake that would lower data consumption and probably lower server load somewhat too.
The things that I don't know are: Does DTLS define a limit on how long a session can remain open? Or is there a timeout where a session must be removed after some period of inactivity? If not, do the implementations of DTLS define one themselves?
Is there any thing else that I may be overlooking as to why this wouldn't work? Or is there something more straightforward that I'm not thinking of?
Timeouts are application specific, and you can set them as high as you need, or just keep the connections around as long as you can (eg. with a fixed number of usable connections, timing out the least recently used when a new one is opened).
Session resumption data can be held for as long as both parties agree the resumption data is still good (eg. no underlying certificates have expired). Session resumption should be at least as cheap as manually installed symmetric keys.
So a sensible approach seems to be to just try continuing the session if the sending party still has it open, fall back to session resumption on error, and if that doesn't work go through the full handshake again. There don't necessarily need to be agreed-on times for any of that.
(and making some uninformed assumptions about how often that needs to happen)
My feeling is, an ip-address change after a quiet periode is assumed. If that is assumed, the "DTLS session timeout" is the timeout of "NAT(like)s" on your ip-route. And that NAT timeout is still (too frequently) 30s.
If there are no "NAT(like)" on your ip-route, and so the peers are able to exchange ip-messages by their static (not changing) ip-address and port, then there is no such DTLS timeout. Except, as already answered, your application requires that. There are also some discussions in the IETF when the exchange the connection keys for some security reasons. But the number are rather high (except you want to use AES128_CCM8).
since DTLS is connection-less
DTLS requires a context with a master-key and the "association keys" (TLS "connection keys"). That master-key is assigned to the DTLS session id, and the "association keys" are usually assigned to the ip-address and port. The DTLS session resumption is then used in scenarios, where the addresses may change (e.g. because of "NAT(like)s", or, because the peers are entering a sleeping mode and gets a new ip-address on wake-up). With such ip-address changes, the DTLS session resumption is used to refresh the assignment of the "association keys" with the new address. A DTLS resumption is more, it uses also new "association keys", but it's mainly done to overcome the address change.
The most obvious solution would be to just use symmetric keys
Between PSK and x509, there is also RPK, which offers similiar security as x509 with less data used. Also PSK_ECDHE cipher suites may be a choice.
And hopefully DTLS CID will make CoAP/DTLS more efficient. At least for my tests, experiments and usage over the last 2 years, that was the technique, which brought back CoAP into "must be considered"!
Related
I'm working on a network program and I don't want anyone to know what kind of information is being passed when they sniff the network. Would using TLS achieve this? My main reason is that I want to keep the protocol I'm using to myself for now. If not please tell me if there is anything that can achieve my goal.
It depends on a lot of things, e.g. what your exact threat model is, and how much information leakage you can tolerate.
For TLS to provide adequate protection, these assumptions must be true:
Obviously, you should use a correct implementation, otherwise, if for instance, you are using SecureTransport from iOS 7.0.4, all bets are off.
You should enforce a minimum version requirement and only support secure ciphersuites. If you allow downgrade to SSLv2, you are setting yourself up for problems.
You check for validity of the server public key. You'd be surprised how many client apps skip this.
You use client certificates to authenticate the client, as well as the server, otherwise, it is possible to write a phony client that talks to your TLS server and reverse engineer your protocol. (You can also authenticate the client early in the protocol lifecycle using other means, but that part of your protocol would not be safe).
You keep the private keys secure.
(If you are using X509 certificates and trust chains:) Certificate authorities that you trust do what they are supposed to do, i.e. not sign certificates in your name for others.
You will still leak some packet length and timing information that you hope would not be complete enough for the reverse engineer.
The attacker does not control your client or server or have access to the binaries on any side. If, like an iPhone app, you are giving away the client binary, you have already lost.
Your higher level protocol cannot be tricked into say, redirecting to another server blindly, or lose its mind and do some other crazy thing when the client secure channel is interrupted. This can be hard to notice at times and depends on many other factors.
Something else I have probably missed here.
Would TLS prevent others reverse engineer my protocol?
Probably not. Pentesters do it all the time. They use something like Burp Suite to proxy the connection and watch all the web requests.
If not please tell me if there is anything that can achieve my goal.
Common practice is: if you don't want it stolen, copied, pilfered, abused, etc, then you don't put it on a client. So all sensitive code and data goes on a server you control. Since the client gets to see the request, you have to remove all sensitive information from it.
We have a web service that acts as a gateway between our clients and another service. The clients send messages to, and receive random messages from, the third-party service. The client's server opens a channel to our web server via a secure socket in order to receive the incoming messages (and not have to poll the server every few minutes).
My question is: is it safe to leave this channel open indefinitely, or should we periodically close and re-open it to obtain new credentials (session keys)? If the latter, how often (hourly, daily, weekly) would be considered "best practice"? I've found a lot of information on secure communications, but nothing to answer this specific question.
Thanks
SSL/TLS (which I'm going to assume you're talking about here) does NOT automatically refresh/renegotiate the session keys being used. There is a renegotiation procedure built-in to the protocol to allow the session keys to be changed within an active session but that procedure was found to have a significant vulnerability a few years back and the renegotiation process was changed (in RFC 5746, see here) to resolve the problem. If you do want to renegotiate the session keys for SSL/TLS, make sure you're doing it in the manner described in this RFC.
That does not, however, answer your original question of IF the session keys should be changed. The answer is...it depends on your security requirements. A good guideline to be used is that any encrypted communications can be eventually decrypted if you see enough of the encrypted data (how practical/doable this is can vary wildly). So, changing your keys every so often is a very good thing to do. If you're passing a small amount of data over a secured connection and the data isn't that sensitive, then you can get away with doing this on a not-so-regular basis (indeed, your SSL/TLS session is probably going to get broken and restablished due to timeouts on one of the two parties on a somewhat regular basis anyway...). If you've got a very sensitive dataset and you're sending alot of data, then I'd suggest rotating the keys every day or so to mitigate this risk (just do it in a secure manner).
so I have this TCP connections between my server and client, and anyone can connect to my server. But I want to make sure that the client is really using MY client application and not just faking messages from a fake TCP client. What would be the ways to do that, check that the connection really is from my game client?
Thanks!
EDIT
If I'm gonna use TLS, can I solve that problem?
There will probably not be a complete solution to your problem, since whatever you do, the other party might always take your program, run it in a monitored environment, manipulate the runtime data and let it use its "secure" network protocol. Since the client application is in uncontrollable hands, you can never be sure that it is your own program.
Baby example: My application runs your application and plays back the data to your server, and forwards your response back to the application. How can you tell?
That said, it might be a very promising "99%" approach to use SSL and hardcode the client's private key into the application -- with some trickery you can try and make it hard to find (e.g. see how Skype does it). If you then also build integrity checks into your program that figure out whether anyone is manipulating the memory or debugging into your program, you can try and make it a bit harder for a potential adversary. (But note that you will always have to ship the private key with your application, so it isn't really safe from discovery.)
Others have suggested useful answers to your question, but I'm going to suggest another approach. Re-examine your requirements.
Ask yourself why you want to know the identity of the client program. Is it so that you can trust your client program more than you trust 3rd-party client programs?
If you need to trust the identity or integrity of software that you have already shipped to your customers, I claim your security model is broken. Once the software runs on a client's PC, you should assume it is evil, even if you originally wrote it.
Any status, any command, any data whatsoever that comes from the network must be checked before it is relied upon.
My default response is to use a challenge/response authentication.
After connection, send a random number from the server to the client
The client then computes, using a hash/key/.... a response message and returns that to the server
If the response matches the servers computation, your chances of authenticity are better. Note though that a reverse engineer of your client will leave this method open to fraud.
You could use a public/private key pair in order to verify that you are who you say you are.
http://en.wikipedia.org/wiki/RSA#Signing_messages
I'm in the designing stages of a custom tcp/ip protocol for mobile client-server communication. When not required (data is not sensitive), I'd like to avoid using SSL for overhead reasons (both in handshake latency and conserving cycles).
My question is, what is the best practices way of transmitting authentication information over an unencrypted connection?
Currently, I'm liking SRP or J-PAKE (they generate secure session tokens, are hash/salt friendly, and allow kicking into TLS when necessary), which I believe are both implemented in OpenSSL. However, I am a bit wary since I don't see many people using these algorithms for this purpose. Would also appreciate pointers to any materials discussing this topic in general, since I had trouble finding any.
Edit
Perhaps the question should have been: is there a best practices approach for secure passwords over unencrypted tcp/ip? If not, what are the reasons for selecting a particular method over others? (The Rooks answer is closest in spirit to this question so far, even if it does violate the letter).
Edit, part deux
I'm primarily interested in the case of client-server authentication, where there is an expectation that both parties have a shared secret (password) a priori.
You should have a look at "Diffie-Hellman key exchange":
Diffie–Hellman key exchange (D–H) is a cryptographic protocol that allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher.
Once you have exchanged a key, you can encrypt your password with this key and transmit it over the insecure protocol.
I still think that SSL is by far your best choice, after all why reinvent the wheal when so much can go wrong? You don't have to buy an expensive certificate if your have a list of "good" and "bad" (compromised) certificates. openSSL is completely free, and i don't see a good reason not to use it.
Some things you might not know: ssl handshakes can be resumed.
Also you can use SSL/TLS over UDP to reduce overhead its called DTLS.
You could use a challenge-response algorithm. The algorithm goes like this:
The server sends a random string to the client.
The client combines this string with the password (by combining, you can xor them or just append them).
The client calculates a hash (for example, SHA1) of the result, and sends it to the server.
The server calculates the same hash using this random number and the real password.
The server compares the two hashes.
Since you shouldn't store a password in plain text, but as a hash instead, the client should calculate this hash at the very beginning.
There are possibly several libraries implementing this, so you probably don't need to code it yourself.
I'm using RSA to encrypt communication between a server and a client.
Lets say we have 2 Asymetric keys, key 1 and key2.
The server has key1 (Private) from the start and the client has the key1(public)
So here is the scenario:
the client generates key2
client connects to the server
sending key2(public) encrypted with key1(public)
from now on the server will send all data encrypted with the key2(public)
the client sends some random data to the server
the server sends back the same data hashed
the client verifies that the data is right
As far as I can see this should prevent a man-in-the-middle attack, or am I missing something?
At point 7 the client should know if someone is trying to give the server the wrong key to encrypt with, as no one else but the server can decrypt key2(public).
If there is anything that can be done to improve the security please tell me.
The best thing you can do to improve the security is to use an existing design and not try to reinvent the wheel. I'm not saying that what you've done is necessarily wrong, but just that many people much smarter than you and me have spent a lot of time thinking about this problem. Use TLS instead.
As long as key1 (private) has not been intercepted somehow by a third-party, your scenario looks secure.
I think I saw this somewhere in a paper actually. In it, Alice gave Bob an unlocked box (key 1 public), then Bob put a bunch of his own boxes (key 2 public) in it, locks it and sends it back to Alice. Alice then opens the box(key 1 private), and now she can securely seal the boxes that Bob just gave her.
Despite the box analogy, that's essentially what you're doing, so I'd say its secure.
I agree, just use TLS.
Also, what value do steps 5 through 7 provide? A MITM wanting to do an attack that would work after steps 1-4 (e.g. DoS of some sort by passing n transactions through and then stopping, forcing a retry from the start) could do so just as well after 5-7. What do they add?
-- MarkusQ
No, this protocol is not safe.
A man-in-the-middle can intercept the data sent by the client and send whatever it wants to the server, since you haven't specified any mechanism for the server to authenticate the client or verify the integrity of messages it receives.
Sure, you could doctor up your protocol to fix these glaring problems, but there would be others. If you ever fix them all, you'd have something that maps to TLS or SSH, so why not just start there?
#Petoj—the problem I was focusing on was that of the server trusting the messages it receives; your proposal doesn't provide any security there. However, if you are worried about confidentiality, you still have a problem, because the MITM could pass messages back and forth unaltered until he sees what wants to find because you don't have any privacy on the client messages.
Your proposal seems to be aimed at ensuring the integrity of messages from the client. You've developed the protocol to the point where the client can't distinguish between an attack and a network failure. Rather than trying to help the client determine whether the server acted on a tampered message, allow the server to verify the integrity of the message before acting on it.
I will agree with Greg that you are reinventing the wheel. What you are essentially describing is some basic form of key exchange. Incidentally, in order to ensure that it is secure against man-in-the-middle attacks you must also be certain of the server's identity, i.e. ensure that the client can know with certainty that what it believes to be public(key1) really is the server's and not the man-in-the-middle's (e.g. using a CA or having the server's public(key1) in secure storage on the client side.)
Moreover, there are additional considerations you must be aware from a systems standpoint, such as:
asymmetric key encryption is slower than symmetric key encryption, which is one of the reasons why existing solutions such as TLS will use asymmetric key encryption only to negotiate a temporary symmetric key, which is then used for channel encryption.
if traffic analysis by a third-party succeeds in cracking a temporary symmetric key, you have not compromised you asymmetric key pair. You are encouraged to re-negotiate the temporary key relatively often for this reason. Arguably, generating a new key2 in your scenario would mitigate this aspect.