Question: I'm a software developer working with hardware devices that are deployed on the field. Every now and then, I would need to update the hardware's firmware (upgrades, patches, etc)

I'm thinking of now, implementing a secure channel to upgrade this firmware, and for some checking to be performed by the hardware before accepting this firmware. 

I have a basic understanding on key exchange protocols, encryption ciphers, etc, and that's about it. I do not necesarily know how to apply them in the real world, so I was hoping I could get some help here.

The firmware upgrade would be performed through a custom software that runs on the PC written by me, over TCP/IP. 

My main goals are 

1. prevent the firmware from being leaked to public as it contains our IP.
2. prevent the hardware from running other firmwares other than firmware released by me.

What I do know, on a high level point of view is

1. To encrypt (with a pre defined shared secret key) the firmware on the PC software, and send it over ot the firmware.
2. Once the firmware receives this encrypted data, it will decrypt it with the pre defined shared secret key, and performs the upgrade

My questions are: 

1. Is defining a shared secret key secure in this aspect?
2. Is there a "bread n butter" solution to achieve my requirements?

Answer: 
You're going to need more than application and protocol security. You'll also need robust hardware security. 

It's easy to monitor the data flowing to and from the memory chips, or to read the content of a flash chip. Instructions stored in a CPU's flash memory can be retrieved through the JTAG port. Other side channel attacks include differential power analysis, timing analysis, RF emissions, and even ion-beam microscopic examination of the chips. Defending against all of these (and more) has to be considered and weighed against the value of the IP you're trying to protect.

The Payment Card Industry has created a good [set of standards](https://www.pcisecuritystandards.org/security_standards/documents.php?association=PTS) on defending PIN pads against reverse engineering. You might want to look to them.

It's becoming more and more common to see people reverse engineering hardware to recover the secrets they contain. For an example of someone willing to dig deep, check out [this series of articles on reverse engineering](http://cybergibbons.com/category/alarms-2/friedland-response-reverse-engineering/) the RF protocol for a wireless burglar alarm.
Your question details no computational restrictions so I am assuming I have a modern CPU to solve the problem.

I personally think of shared secret as the lowest form of authentication. What you are describing seems to boil down to "How can this machine trust that the binary package it's being asked to run is in it's circle of trust?".

I assume you have an organization with access to an SSL cert which would form as a trust center. The CA for the SSL confirms the key and all keys signed by that key would be trusted. They are very inexpensive and quick to set up if you lack one.

From there on you have a plethora of protocols to choose from. My instinct would be not to wander into fresh territory, but rely on proven methods. TLS provides for cheap transport and verification of origin. ECDHE provides good forward secrecy. SSH gives you the first privilege channel to generate the client keys and extract the public part for signing if the machines are too remote for a site visit.

The governing principle you should be thinking of is "How do I solve this with systems administration instead of programming?".