How to securely share key between two remote devices?
What you are looking for is a public/private key pair otherwise known as SSL in the computer world.
An SSL certificate as you mentioned is enough security since to find out what is being sent you need the private key of the certificate and you cant get that without breaking into the server.
If you don't want to use SSL another option would be to use a hardcoded public/private key pair into the client/server which would act just like SSL but without having a signed certificate.
If the question is understood properly, what is really asked here is how to do a key-exchange.
Having implemented this in the same manner discussed for a security product, the following general approach works independent of the underlying transport protocol (and further does not make any assumptions about its underlying security):
Client generates a (random) transaction key using some (presumed) good IV and strong pseudo-random algorithm suitable for AES256 (or better) encryption.
Client generates a (new random) symmetric response-key using same process as in step (1).
Client encrypts the response-key (2) with the transaction key from (1) ... using AES256 or whatever preferred algorithm.
Via PKI, the client asymmetrically-encrypts the transaction key (1) for the server (recipient) using Server public-key. This will ensure only the Server can read the transaction key (1).
Generate a payload in which the client (sender) is identified, associated with their public-key on the server (receiver) side. In this payload will be the (PKI encrypted) transaction key (1) and the (AES encrypted) response-key (2). There is more to this such as hashing contents to ensure non-repudiation, etc - but let's focus on the key exchange...
Client sends the payload to the Server. It is recommended this be done via TLS, etc but this is not strictly necessary as the encryption is sufficient to protect the keys. However, being sure the client is sending the payload to the [right] server (receiver) without eavesdropping improves the security of the key-exchange.
Via PKI, (using Server private-key), decrypts the first part of the payload: the transaction key.
Using the transaction key, the response-key is decrypted using AES256 (must be same algorithm and IV as used for response-key encryption - should be part of payload).
At this point, the client waits for a response from the Server.
Server, using the response-key that the Client knows (he generated it) for this transaction, can then encrypt any content bound for the Client simply using AES256 (some symmetric algorithm).
Client uses symmetric algorithm and response-key to decrypt Server response.
Provided the PKI secret-keys are not compromised, good salts, IVs, etc are used... this process is very solid (used by security organizations around the world).
Note that ANY cryptography can be broken EVENTUALLY. Using this transaction-based process with new (randomness of key is important) (large) pseudo-random keys for each request/response pair, it very difficult to compromise the conversation.
Using this method, even if ONE transaction-key is compromised, it very much limits the exposure since access would only be gained to a single transaction at a time.
Secure Sockets Layer (SSL) seems to be the answer you are looking for. Here's a quote from the Wikipedia page:
They use X.509 certificates and hence asymmetric cryptography to assure the counterparty with whom they are communicating, and to exchange a symmetric key. This session key is then used to encrypt data flowing between the parties. This allows for data/message confidentiality, and message authentication codes for message integrity and as a by-product, message authentication.
Also though, you might just want to have a look at RSA and Diffie-Hellman algorithms which can be used in a client/server model to exchange keys securely. They however, have many types of attacks attached to them; the man-in-middle is one of them, in which an intruder might just step in and steal the key. Another attack possible is the brute-force, in which an intruder might guess the key you are trying to transfer.
If you want to exchange keys securely using these algorithms, make sure you hash them using the MD-5 or SHA-X algorithms. You can even encrypt them if you have space, using DES/Double DES/Triple DES, or AES-128/192/256 encryption algorithms.
Read through this:
Before a client and server can begin to exchange information protected by TLS, they must securely exchange or agree upon an encryption key and a cipher to use when encrypting data. Among the methods used for key exchange/agreement are: public and private keys generated with RSA (denoted TLS_RSA in the TLS handshake protocol), Diffie-Hellman (denoted TLS_DH in the TLS handshake protocol), ephemeral Diffie-Hellman (denoted TLS_DHE in the handshake protocol), Elliptic Curve Diffie-Hellman (denoted TLS_ECDH), ephemeral Elliptic Curve Diffie-Hellman (TLS_ECDHE), anonymous Diffie-Hellman (TLS_DH_anon), and PSK (TLS_PSK). The TLS_DH_anon key agreement method does not authenticate the server or the user and hence is rarely used. Only TLS_DHE and TLS_ECDHE provide forward secrecy. Public key certificates used during exchange/agreement also vary in the size of the public/private encryption keys used during the exchange and hence the robustness of the security provided. In July 2013, Google announced that it would no longer use 1024 bit public keys and would switch instead to 2048 bit keys to increase the security of the TLS encryption it provides to its users.