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: 
With respect to your goals you need:

1. Data confidentiality->Encryption. The question is public one or secret one. I guess you need a secret one in which only the owner of the key can encrypt and decrypt. You don't want anyone to encrypt firmware.
2. That implies an integrity mechanism. If you use a secret key scheme then you want either an authenticated block cipher or a secure combination of MAC (message authentication code) and encryption. Encrypt-then-Mac approach tends to be the more secure for various reasons.

For your questions:

1. Secret key sharing is secure as long as the involved parties are trusted and as @Ricky mentioned if you can't define different key per device.
2. You deploy the secret key at your hardware devices and the server and then you use that with AES for encryption. For authentication unless you use an appropriate cipher that combines both you **MUST** use different keys for the MAC authentication.
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.