Two servers -- secret key communication

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Two servers -- secret key communication

Post by alex.barylski »

EDIT | I think I have answered my own question while asking it and thinking out loud...so please read the whole thing (especially the last sentance) before answering.

I've been working all day and night so my mind is semi-fried...but...

I have two servers:

A. Is a consumer of web services
B. Is a provider of web services

A: Is given a secret key which it must pass along each request to B when it wish to receive data back. This key is shared between the two servers and as long as the key is identical the provider returns a result to the consumer which it the does as it' pleases with.

Great but unless SSL is enabled...interception of that key is a possibility. So:

1. Use SSL -- no thanks way to much processing going on
2. Use some session technique where the consumer uses the KEY to gain a temporary SID

The latter is what I am trying to figure out (if it's feasible or not). I will probably have a better understanding tomorrow but using encryption of any kind is out of the question. Basically that key needs to be used once per session to minimize interception...then I thought...

If server A and server B are both known to have fixed IP addresses could it not be assumed then that any incoming request to server B (provider) given the IP address of server A (consumer) is indeed the real consumer? Sure the IP address can be spoofed but the server (provider) would return results and for what? If you spoofed the IP the results would not reach you but they would indeed go back to the consumer server and likely just be dropped...so unless you were also intercepting packets between these two points AND spoofed the IP you wouldn't end up with much.

If someone has managed to intercept traffic...regardless of what solution I use the data is seen. I would have to use private key encryption like Blowfish or similar or public key like SSL. Neither of which would be very good, except at securing the request.

Ugh....maybe I should just encrypt the data using the secret key and be done with it...a session approach would not stop anyone from sniffing packets it would only prevent requests from being sent to anonymous servers but if the IP of both servers is known...I could just check to ensure calling server IP is the right one for the given key. This way I avoid encryption and only risk people intercepting the data...in which case I could have encryption just in case someone requires it.

Anyways...does everything I said make sense...after listening to me babble/brain dump...does the conclusion I have finally come too make sense? Using IP validation only UNLESS greater security is needed in which case secret key encryption would be used as well???

Cheers :)
User avatar
Weirdan
Moderator
Posts: 5978
Joined: Mon Nov 03, 2003 6:13 pm
Location: Odessa, Ukraine

Re: Two servers -- secret key communication

Post by Weirdan »

When transferring a chunk of data between two points, several attacks could be possible:
1. Client is not who it said it was
2. Server is not who it said it was
3. Data is being read by someone in the middle
4. Data is being modified by someone in the middle
5. Data is being captured by someone in the middle and later sent to your server again.

Obviously you're not concerned with scenario 2 and 3 (as you specifically rule out encryption and not talking about server identification).

Remaining points (except 5) are easily solved with signing data (it's not the same as encryption). Instead of sending shared secret key your client would use it to sign the data it transmits and server, knowing the key, would verify that signature on its side. The simplest variant of signature would be calculating a hash function over data + secret key:

Code: Select all

 
// client side
$signature = sha1($data . $key);
 
Generated signature is then transmitted alongside with data. Verification is simple as well:

Code: Select all

 
// server side
// It's assumed that we have extracted data and signature to variables already
if (sha1($data . $key) == $signature) {
   // valid request
} else {
   // invalid request
}
 
The key is never transmitted (it's secret key after all).

This, however, does not solve the problem of later retransmission of the request. This is usually solved by requesting a one-time token from the server and adding it to the following request.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Two servers -- secret key communication

Post by alex.barylski »

Instead of sending shared secret key your client would use it to sign the data it transmits and server, knowing the key, would verify that signature on its side. The simplest variant of signature would be calculating a hash function over data + secret key
Hmmm...I'm glad I asked this question after all...while I am not overly concerned with interception...modification is certainly a much bigger problem. Thank you for the solution
This, however, does not solve the problem of later retransmission of the request. This is usually solved by requesting a one-time token from the server and adding it to the following request.
How do you mean re-transmission of the request???

Thanks again. You saved me from a potentially embarrising exploit. :D
User avatar
Weirdan
Moderator
Posts: 5978
Joined: Mon Nov 03, 2003 6:13 pm
Location: Odessa, Ukraine

Re: Two servers -- secret key communication

Post by Weirdan »

Hockey wrote:
This, however, does not solve the problem of later retransmission of the request. This is usually solved by requesting a one-time token from the server and adding it to the following request.
How do you mean re-transmission of the request???
Suppose you're buying something from me via ebay. Say Mac Mini for 100$. I'm prepared for that and installed necessary hardware on your cable internet connection. So while you're performing a transaction via paypal I'm catching and recording all your traffic. Later on (possibly after shipping you that mac), I'm replaying that traffic into the wire, 20 times in a row. If paypal had no measures in place against replay attack it would additionally transfer 20 x 100$ from your account to mine. This is called replay attack. Of course it could be much more subtle than I described.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Two servers -- secret key communication

Post by alex.barylski »

OK...makes sense.
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Re: Two servers -- secret key communication

Post by Mordred »

One-time tokens should be carefully implemented to be one-time, or replay attacks would still be possible.

1. Just timestamp a random nonce - this is the equivalent of PHP sessions. Hijacking and replay can be done only in a limited timeframe.
2. Exchange a signed nonce, then in each packet sign the nonce and an incrementing counter, then identify packets with wrong counter values as replay attacks.

Symmetric encryption with a hash of the shared key + negotiated (i.e. synchronised) random nonce is also viable.

If synchronising shared secrets is not possible (although in your case both servers are under your control, so it shouldn't be a problem) there are other solutions for secret key exchange.
Post Reply