¿Qué tan peligroso es transmitir los últimos N bytes de un datagrama en texto plano?

3

Estoy desarrollando software para un proyecto de satélite universitario, y actualmente estoy trabajando en los protocolos de comunicaciones. Aquí están las restricciones:

  1. Se debe suponer que los paquetes de radio no tienen más de 256 bytes
  2. Los paquetes de radio deben incorporar algún tipo de corrección de errores hacia adelante
  3. Los paquetes de radio deben estar cifrados, si es posible.

Con esto en mente, hemos seleccionado el Reed-Solomon protocolo de corrección de errores hacia adelante , que proporciona 223 bytes de datos para una longitud de mensaje de 255, agregando 32 bloques de paridad para hasta 16 bytes de recuperación de errores.

El contenido principal de nuestras transmisiones se basará en un protocolo de transferencia de archivos desarrollado internamente que le permite seleccionar el binario dentro de un archivo en "trozos" para la transmisión. Estos trozos están restringidos para ser de longitud 223, por Reed-Solomon. Los archivos con los que los enlaces ascendentes y descendentes serán archivos tar, que contendrán los horarios de la misión y los scripts de shell.

Para permitirnos multiplexar a múltiples satélites en la misma frecuencia (o lo suficientemente cerca como para que todos puedan recibir un paquete determinado), y para ofrecer cierta protección contra ataques de repetición, a cada "sesión" se le asigna un ID de sesión de 1 byte. que debe caer en la clase de equivalencia asignada de un determinado satélite para que el satélite preste atención. También debe ser el siguiente en la secuencia en función del tamaño del módulo que asignamos (16 en este caso, para permitir 16 sats en la misma frecuencia). Esto formará parte de los bloques de texto sin formato que transmitimos.

También tenemos, según los requisitos de la misión, acceso directo al shell a través del uso de paquetes de "reenvío de comandos", que esencialmente llenan los 223 bytes con algunos metadatos, y una cadena que se pasa directamente al shell con permisos de raíz. Este es el gran agujero en nuestra configuración actual, pero no se puede hacer más restrictivo, ya que necesitamos un control máximo sobre el satélite desde el suelo en situaciones de emergencia.

Recientemente obtuve la aprobación para volar AES, que creo que usaré para cifrar estos paquetes por completo, y evitar cualquier acceso no deseado. Tenemos acceso completo a libcrypto desde OpenSSL. Puedo incluir metadatos adicionales para proporcionar autenticación y la cadena que se ejecutará en el shell, pero aún necesitamos que dicha cadena tenga una longitud de al menos ~ 100 bytes. Todo esto debe encajar en un paquete de radio, ya que no podemos estar seguros de que los paquetes llegarán a la radio en el otro extremo.

He estado pensando que podríamos usar AES-192, ya que nos daría 216 bytes encriptados, dejando que los últimos 7 bytes pasen a texto sin formato. Incluso podríamos exigir que se eliminen o que se rellenen con datos de un PRNG, pero me gustaría mantenerlos totalmente utilizados si es posible. El texto sin formato probablemente esté bien incluso para la transmisión de fragmentos de archivos binarios, cuyo contenido es mayoritariamente aleatorio de acuerdo con mi análisis.

¿Existe una forma fácil de asegurar el orificio de la carcasa raíz y, al mismo tiempo, proporcionarnos una tasa de enlace descendente "decente"?

    
pregunta ijustlovemath 07.08.2017 - 16:49
fuente

0 respuestas

Lea otras preguntas en las etiquetas