¿Sería buena una clave secreta compartida predefinida aquí?

Con respecto a tus metas necesitas:

1. Confidencialidad de los datos - > Cifrado. La pregunta es pública o secreta. Supongo que necesita uno secreto en el que solo el propietario de la clave pueda cifrar y descifrar. No quieres que nadie cifre el firmware.
2. Eso implica un mecanismo de integridad. Si usa un esquema de clave secreta, entonces desea un cifrado de bloque autenticado o una combinación segura de MAC (código de autenticación de mensaje) y cifrado. El enfoque de Encrypt-then-Mac tiende a ser más seguro por varias razones.

Para sus preguntas:

1. El intercambio de claves secretas es seguro siempre que se confíe en las partes involucradas y como se menciona en @Ricky si no puede definir una clave diferente por dispositivo.
2. Implementas la clave secreta en tus dispositivos de hardware y en el servidor y luego la usas con AES para el cifrado. Para la autenticación, a menos que use un cifrado apropiado que combine ambos, DEBE usar diferentes claves para la autenticación MAC.

Necesitará más que seguridad de aplicaciones y protocolos. También necesitarás una robusta seguridad de hardware.

Es fácil monitorear los datos que fluyen hacia y desde los chips de memoria, o leer el contenido de un chip flash. Las instrucciones almacenadas en la memoria flash de la CPU se pueden recuperar a través del puerto JTAG. Otros ataques de canal lateral incluyen el análisis de potencia diferencial, el análisis de tiempo, las emisiones de RF e incluso el examen microscópico de los chips con haz de iones. La defensa contra todos estos (y más) debe considerarse y compararse con el valor de la propiedad intelectual que intenta proteger.

La industria de tarjetas de pago ha creado un buen conjunto de estándares para defender las almohadillas de PIN contra el reverso Ingenieria. Es posible que desee mirar a ellos.

Se está volviendo cada vez más común ver que la gente invierte el hardware de ingeniería para recuperar los secretos que contienen. Para ver un ejemplo de alguien dispuesto a profundizar, eche un vistazo a esta serie de artículos sobre ingeniería inversa el protocolo de RF para una alarma antirrobo inalámbrica.

¿Por qué reinventar la rueda? Utilice rsync + ssh, scp o sftp.

Su pregunta no detalla restricciones de cálculo, por lo que asumo que tengo una CPU moderna para resolver el problema.

Personalmente, pienso que el secreto compartido es la forma más baja de autenticación. Lo que estás describiendo parece reducirse a "¿Cómo puede esta máquina confiar en que el paquete binario que se le pide que ejecute está en su círculo de confianza?".

Supongo que tiene una organización con acceso a un certificado SSL que se formaría como un centro de confianza. La CA para el SSL confirma la clave y todas las claves firmadas por esa clave serían de confianza. Son muy económicos y rápidos de configurar si no tiene uno.

A partir de ahí tienes una gran cantidad de protocolos para elegir. Mi instinto sería no vagar en territorio nuevo, sino confiar en métodos probados. TLS ofrece transporte barato y verificación de origen. ECDHE proporciona buen secreto hacia adelante. SSH le da el primer canal de privilegio para generar las claves de cliente y extraer la parte pública para firmar si las máquinas son demasiado remotas para una visita al sitio.

El principio de control en el que deberías pensar es "¿Cómo puedo resolver esto con la administración de sistemas en lugar de la programación?".