¿Cómo crear un protocolo de comunicación UART seguro?

Me preguntaba cómo crear un protocolo de comunicación UART/USB seguro. Lo necesito para la comunicación entre un microcontrolador y una PC. Tengo ~ 10 comandos y pensé en usar 10 comandos de reconocimiento separados para cada uno de ellos.

El intercambio debería ser así:

  • La PC envía un comando de activación a través de UART
  • µC reconoce que la PC está conectada y envía su comando a la PC, p.0x01
  • La PC hace lo que se le pidió (algunas cosas de hardware) y responde ~0x01cuando termina (niego el número para crear una "distancia" mayor entre los dos números)
  • µC sabe que envió 0x01y está esperando ~0x01de la PC. Si ~0x01vuelve a aparecer algo diferente, el µC sabrá que algo salió mal y enviará una nueva solicitud o un mensaje de error.

El caso de que el µC envíe 0x01, la PC lo comprenda 0x02y ~0x02lo devuelva, pero el µC lee ~0x01debido a algún ruido sería bastante malo.

¿Qué tan seguro es eso en términos de transmisión, o cómo puedo hacer esto más seguro?

Es posible que desee revisar la pregunta mía relacionada y las muy buenas respuestas.
Por "más seguro" entiendo que te refieres a menos propenso a errores de transmisión, sin agregar criptografía, etc. para resistir las escuchas y demás. Incluso eso es un campo bastante amplio: en.wikipedia.org/wiki/Error_detection_and_correction
Tienes razón, suena un poco confuso. Errores de transmisión, por supuesto. Activaría el bit de paridad UART, ya que el µC lo admite en el hardware y debería ser muy rápido, pero aún es un poco inseguro, si solo cambian los bits correctos debido al ruido...
Es posible que desee buscar la codificación de Hamming . Tomará hasta 16 comandos (4 bits) y los expandirá de manera sistemática a 7 bits (que se pueden transmitir a través de un UART estándar). Puede optar por corregir cualquier error de un solo bit o detectar si se han recibido dos bits.
1) 7 bits + un bit de paridad es unidireccional y es simple. No detectará todos los errores posibles, pero detectará muchos. 2) Un método más robusto es enviar dos bytes, primero con el comando real y segundo con el 'no' del primer comando. 3) Aún mejor es enviar un byte de 'comando entrante', seguido del comando, seguido del complemento del comando, seguido de un byte de 'final del comando'. Los bytes de 'comando entrante' y 'fin de comando' deben seleccionarse para que no se superpongan con ninguno de los bytes de comando y complemento.
dado que solo necesita 10 comandos, código hamming + bit de paridad es obvio.
No sabía sobre Hamming, gracias, ¡eso suena muy prometedor!
Si solo necesita 10 comandos, puede colocar dos copias en cada byte (para redundancia), más bits de paridad. O como tiene un espacio de símbolos de 256 símbolos y solo necesita 10, simplemente puede elegir símbolos diferentes al máximo (todos los símbolos difieren en varios bits) o elegir solo símbolos con números pares de unos y ceros. Ciertamente no tiene que preocuparse por los errores de un solo bit.
Se ha pensado decentemente en el formato de los datos en este momento, pero también debe pensar en la secuenciación y los mensajes potencialmente retrasados ​​​​debido al almacenamiento en búfer; es posible que no desee eso, pero de manera predeterminada lo tendrá en el extremo de la PC. Dado que menciona USB (presumiblemente UART conectados por USB), también piense en la latencia que puede introducir y los posibles problemas relacionados con la (re) enumeración.
Los códigos Hamming tienen una utilidad limitada para la comunicación UART, dado que una falla que ocurre justo antes del inicio de un paquete puede causar que todos los datos posteriores se enmarquen incorrectamente. En general, también se puede pensar que si alguna parte de un paquete falla, todo el paquete debe considerarse inútil.
Podría valer la pena ver cómo se intercambian los mensajes SECS/GEM entre equipos. Es posible que pueda robar algunas ideas de eso. Se toman muy en serio la gestión y la precisión de los mensajes.

Respuestas (2)

Creo que debería definir comandos más largos, incluida probablemente la suma de comprobación o CRC, y esperar una condición de error o ACK/NACK.

Puede tomar ejemplos de protocolos sencillos como TFTP ( RFC 1350 )

Para una comunicación segura, debe considerar todos los hilos posibles a su línea de comunicación. Por lo tanto, debe definir si el sistema es accesible desde el exterior (sistemas de terceros, por ejemplo, inalámbricos)

En general, tienes que pensar en los siguientes hilos:

  • repetición
  • omisión
  • resecuenciación
  • manipulación
  • demora
  • inserción
  • corrupción

Las medidas estándar contra hilos son:

  • Secuenciación o marcas de tiempo
  • supervisión del tiempo
  • códigos únicos de origen y destino
  • respuesta
  • procedimiento de identificación
  • algún tipo de suma de comprobación, código hash...
  • técnicas criptográficas algunas de estas ya las tienes implementadas con tu protocolo sencillo.
¿Cómo crear un protocolo de comunicación UART seguro?
RespuestasAquíPolítica de privacidad1y, 0v