What algorithms can be used for device pairing?

Question

I am to implement a system where android devices connect to a central server and have to register with different user accounts, so I have decided to create a pairing dance similar to what can be observed in bluetooth pairing, or software like the apple remote pairing with the itunes library. I'm searching information on what encryption algorithms can be used during this communication using a separate communication channel for the encryption key. The algorithm I've thought of would follow these steps:

1. The device powers on and calls a fixed server to announce itself.
2. The device shows a few random numbers on the screen (eg. 392582).
3. The user has to log in on the server with a web browser into his account and type in the number sequence seen on the device (might be done on the android device itself).

During step 1 the client would communicate to the server through SSL. The number shown to the user in step 2 would be part of a longer static predetermined string which would be hashed. The server and client would exchange the hash and verify it is the same. If it is, it means the pairing is OK. Some questions haunting me:

1. Is this actually sound or paring devices is done in other ways?
2. Is using MD5 hashing enough for this or should I be using other hashes?
3. What length and time expiration should the screen code have in order to prevent collisions with other potential users?
4. What refinements can be done to improve the authenticity of the connection? I've though of replacing the static longer predetermined string to hash with a random string. The client would send the seed of the random number generator during the first step. A man in the middle would still get it, but would this reduce hash collisions with other users?
5. I lack the technical security jargon, maybe this is a well studied process and tons of wikipedia articles exists on it? The information on wikipedia about bluetooth pairing/bonding doesn't give out too much technical details about implementation. Where should I look?

Answer 1

On reread I think I see what you are trying to accomplish. User has an account on www.example_business.com and now wants to use example business's new android app. You have decided you do not want the user to have to give full login through your android app. Maybe you require two-factor authentication (where the second factor is the phone), or require certificates, or are afraid of carrier-IQ type keyloggers and do not want to do the full login procedure on the phone.

1. Client opens mobile_app for first time, which asks user for their user_name, and then sends a request to server for token with user_name. (If user_name doesn't exist; do not communicate to mobile app).
2. Server generates random_number (say ten digit base36 with 36^10 ~ 10^15 possibilities initial displayed as lowercase to easily distinguish 0 from O) and sends this to the website. Server sends timestamp + sha256hash(timestamp + user_name + random_number + high_entropy_secret_key_only_known_by_server) to Mobile app and instructions to logon to the website to get the random_number. The high_entropy secret key should be something like: TQy9p4pDDHpZuS3Fimdag6yCtU9YBCt55PntmPyUPD_oxRMW3f that's kept secret on the server.
3. Client logs onto website, reads random_number, and types random_number into mobile-app.
4. Mobile app sends timestamp (from step2), user_name, received hash (from step2) and random_number (from step3) back to server.
5. Server checks that the timestamp is not too old (say less than a day), has not been blacklisted from too many bad attempts, checks that the hash matches the hash of the received data (does this case-insensitive; e.g., lowers case of random_number), and then sends a token to the mobile app linking the two accounts.

As for blacklisting after too many bad attempts; I'd blacklist usernames+timestamps that have failed three times; you can empty out the blacklist every day (since only day old timestamps work); have mobile app restart process with new timestamp/random_number).

I'd use SSL for all transmissions to prevent eavesdroppers. Now for a user not having an account but knowing a valid user_name and trying to brute-force the random number, they'd have a 1 in 10^15 (about 20 million times less likely then winning the lottery) chance of guessing correctly per attempt. But I'd further institute a step where you throttle logins for IP addresses and accounts that are failing syncing attempts too many times.

Answer 2

EEtimes has listings of vendors for the various chipsets of interest. Honestly, the way you asked the question tells me you are overreaching on a project here. Thirty minutes on the site will save you loads of trouble later if you take the time to read some in-depth whitepapers and avoid reinventing the wheel.
The prior poster did you an enormous favor and I am thoroughly impressed with his level of detail on your project's behalf. Hope that helps, iceberg