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.
Related
I have a question about how to encrypt messages between users. Note i will only talk about cryptography theory and not platform dependent code like C++ with Windows Cryptography. I am talking about system programming and not web programming encryption with TLS, SSL, etc...
Also, ignore Certificates and Signing of messages, so just think of the Public keys as already being verified as not fraudulent and messages as being from the correct user.
I believe the best way to reach fast and secure encryption communication between users is to have both users with a session key because symmetric encryption is faster than asymmetric, and using asymmetric encryption (RSA) for the secure transfer of the session key.
I know there are other key agreement algorithms like Diffie-Hellmans, but lets stick with RSA which is what i've chosen.
Please tell me if you see where this might be a insecure (man-in-the-middle attack) or drastically inefficient way of performing encrypted communications.
Theory steps:
i.) Parties = {Server, Client}
ii.) Server: Generate session key (RC4)
iii.) Client: Generate private/public key pair (RSA)
iv.) Client: Send public key to Server
v.) Server: Encrypt session key with Client's Public Key, then send encrypted
session key to Client
vi.) Client: Decrypt session key using Client's Private Key
vii.) Both parties now hold the session key for fast encrypted communications
Server(Server's Session key) <--> Session Key's encrypted packet (Communication medium) <--> Client(Server's Session key, Client's Public/Private key pair)
Thanks!
Assumptions:
Public Key Tampering is not possible.
I think you mean this, by "ignore Certificates and Signing of messages"
Cryptosystem is not broken.
Symmetric cipher is not broken (RC4 is broken, for example)
Asymmetric cipher is not broken
One-way Hash function is not broken
Random number generator is not broken
Under these conditions, that's perfectly safe. In fact what you described in your question is how PGP works.
If you are willing to learn more about attacks against PGP, go here.
And if you are willing to learn basics of cryptology, this is an excellent beginner tutorial.
lets stick with RSA which is what i've chosen.
That's where your biggest vulnerability is.
Protocols such as TLS (which can use RSA) SSH and PGP provide a well defined mechanism for negotiating encryption, and implementations such as openssl provide a documented, tested, portable, robust and we'll tested abstraction layer.
Rolling your own solution carries massive risks of injecting vulnerabilities. And entails ongoing pain in maintenance.
BTW RC4 is considered broken by many people.
I am relatively new to Cryptography. From what I have read, it says that AES is symmetric. Hence there is no concept of Public and Private. So how is AES implemented to secure information transmitted over the web?
To try to explain, when a website uses SSL/TLS for transmitting encrypted data over the transport layer is first establishes the identity of the server (an/or client depending on the certificates used). Together, using Asymmetric crypto (for example RSA) the two sides (client and server) establish connection and using public and private keys, they figure out a symmetric key that they both can use for transmitting data for the remainder of the session. The actual symmetric key is never transmitted.
Once they have done that, they switch to using symmetric crypto (AES, RC4, etc) for the rest of the session using the key that they determined during the previous steps. Symmetric crypto is much, much faster then asymmetric, hence the reason for switching, but since they can't just pass a symmetric key back and forth the first step is needed to figure out what key to use.
This is a very simplistic explanation of the extremely complex tasks that are really going on, but since you said you're a beginner, I'll keep it simple.
Symmetric encryption (AES and others) are also commonly used strictly within the application (not for transmitting data) for storing encrypted data in a database or on a file system. So in that way AES (or others) can be used for website security.
AES Reference
NIST FIPS 197 doc
For a program I am writing, I would like to use TLS (or something similar) to encapsulate my application's protocol. This will minimize both the amount of work I have to do as well as the number of vulnerabilities I could accidentally create.
My program is designed to be peer-to-peer although one or more servers provide some services to help one user locate another (it registers IP address/port combos) but do little else. I want to make this system very fault-tolerant so having these servers act as a Certificate Authority is unacceptable because a compromise of a server or its key would affect too many users. Therefore I plan on using a Web of Trust.
The main problem with using TLS is that the original TLS 1.2 specification (RFC 5246) does not provide for using OpenPGP certificates. It seems to be very x.509 centric. RFC 6091, which obsoletes RFC 5081 and extends RFC 5246, makes provisions for an extension to TLS that does what I want. The problem is that I don't think BouncyCastle implements this extension and I can't find a Java crypto library that does. I also don't want to write my own / contribute to BC because I'm really bad at not making mistakes and I'm also very lazy.
Another problem with this is that BouncyCastle provides "a light weight client-side TLS API" but because this software is P2P, a server-side API is also necessary so that I can use TLS by making it believe that the peer originating the connection is the client. I'm pretty sure that once the handshake is complete that it's the same.
Questions:
Is there any way that I can still use TLS (which I highly doubt)? Is there a protocol like TLS that is designed for P2P, or at least can function in this way (like I believe TLS can), but can work with an OpenPGP certificate? If neither is the case, should I pursue the idea explained in this question and implement my own layer taking concepts from TLS?
Links to RFCs: RFC 5246 and RFC 6091
The only library that I know to support RFC 6091 (i.e. TLS with openpgp certificates) is GnuTLS but I don't know whether you can use something like that in Java. Alternatively you could replicate the SSH semantics, where you store the public keys of your peers using self-signed
X.509 certificates.
In TLS, the X.509 parts are actually handled as opaque blobs:
The server sends its certificate (and some helper certificates, if it wishes so) as (a list of) opaque string(s) of bytes (a three-byte length, followed by the encoded certificate as arbitrary bytes).
When the server asks for public key client authentication, it sends a list of "names" which are supposed to be the encoded X.500 names of the root CA the server will recognize -- there again, opaque blobs (two-byte length).
The client, when (if) it sends a certificate (chain), uses the same format than the server.
As TLS is defined, both client and server are supposed to use the peer public key, which they get in any way they see fit and that's mostly out of scope of the TLS specification: the certificates exchanged over the wire are considered as mere helpers. So there would be no problem in actually sending OpenPGP encoded public keys in those blobs, as long as both client and server expect it -- and since you control code on both, this should be no issue.
Your problem then "simply" becomes a matter of making a TLS implementation accept to hand you the blobs without choking on them. I know of no existing Java-only TLS implementation which will fit the bill, so you may have to write a bit of code -- but I urge you not to fiddle with TLS protocol details except processing of the certificate blobs. Those things are subtle and weaknesses are sooo easy to create...
As far as I know, the Sun/Oracle JSSE implementation only deals with X.509 TrustManagers (which you can customize to handle certain extensions, but would still expect a structurally valid X.509 certificate.
It might be possible to use Java's security API to implement RFC 6091, but I'm not sure how. It's definitely more work than just tweaking the TrustManagers, as you would have to go deeper into Java's implementation of TLS.
Alternatively, if it's for a bespoke server, you could re-use the key material from PGP certificates into X.509 certificates and put the initial PGP certificate (with all its signatures) as a blob in a custom X.509 extension (as it's more or less done here). The problem here would be interoperability, since such an extension wouldn't be a standard. Implementing a TrustManager in Java that is able to understand extension is definitely feasible, and you wouldn't need to dig into the internals of Java's TLS stack, you'd only have to deal with custom TrustManagers to initialize your SSLContexts.
Assuming I've securely exchanged keys with another computer (using Diffie-Hellman perhaps), here's my tentative solution:
packet number + encrypted data + message authentication code (MAC)
The packet number is an incrementally-increased number starting at 0. After that is the encrypted data itself, followed by a MAC of them both. If someone attempts a MITM attack, the MAC should fail to compute. If they attempt a replay attack, the recipient will notice it has already received that packet number.
Is there any flaw in my reasoning here?
Assuming I've securely exchanged keys with another computer (using Diffie-Hellman perhaps)
This is where you face the biggest danger - if the man-in-the-middle manages to control the key exchange (for example, by establishing one key with the client and itself, and establishing another key with server and itself), then the MITM can decrypt (and re-encrypt) everything. Once you've established the secure key exchange, you should be invulnerable to the MITM attack. But the hard part is ensuring that the key exchange is truly secure.
Consult Practical Cryptography (or at Amazon) by Ferguson and Schneier for information about this.
You're not describing a man in the middle attack, but a replay attack.
With a MITM attack the key exchange is intercepted and you say that you already have exchanged keys securely - so it is not the problem.
Replay attacks are easy enough to mitigate against, you include a unique message ID and then check it for uniqueness on the receiving side. Generally each message has an expiry date and time so you don't need to keep an ever growing list of message IDs to validate.
Your approach for protecting against replay attacks seems reasonable to me. You are essentially describing a method called timestamping. Your packet number is a "virtual time" that is used by the recipient to verify that the message was not sent before.
Once the keys have been exchanged then the data cannot be intercepted or spoofed by a third party. (Except when your packet # counter loops. Hypothetically packets from the old window could be replayed as being from the new window.) The solution to this problem is timestamping (as others have mentioned.) Again, though, this can be sabotaged if the attacker is able to compromise in some way the system time. (If they are a man in the middle, they could hypothetically imitate an NTP server and in that way modify a client's system time.)
What an eavesdropper COULD do however is to insert himself between the two parties and disrupt the channel. This would likely cause a new key exchange to occur which could be observed. In order to make key exchange truly secure, you must use 3rd party validation or a pre shared key which only the two communicators know.
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.