Как создать безопасный протокол связи UART?

Мне было интересно, как создать безопасный протокол связи UART/USB. Мне это нужно для связи между микроконтроллером и ПК. У меня есть ~ 10 команд, и я подумал, что буду использовать 10 отдельных команд подтверждения для каждой из них.

Обмен должен проходить так:

  • ПК отправляет команду пробуждения через UART
  • µC распознает, что ПК подключен, и отправляет ему команду, например.0x01
  • ПК делает то, о чем его просили (некоторые аппаратные вещи), и отвечает ~0x01, когда это делается (я отрицаю число, чтобы создать большее «расстояние» между двумя числами)
  • µC знает, что он отправил 0x01и ожидает ~0x01от ПК. Если что-то другое, чем ~0x01возвращается, микроконтроллер узнает, что что-то пошло не так, и отправит новый запрос или сообщение об ошибке.

Случай, когда микроконтроллер отправляет 0x01, ПК понимает 0x02и отправляет ~0x02обратно, но микроконтроллер читает ~0x01из-за некоторого шума, был бы довольно плохим.

Насколько это безопасно с точки зрения передачи или как я могу сделать это более безопасным?

Возможно, вы захотите просмотреть мой связанный вопрос и очень хорошие ответы на него.
Под «более безопасным» я понимаю, что вы имеете в виду меньшую склонность к ошибкам передачи, отсутствие добавления криптографии и т. Д., Чтобы противостоять подслушиванию, а что нет. Даже это довольно обширное поле: en.wikipedia.org/wiki/Error_detection_and_correction .
Вы правы, это звучит немного запутанно. Ошибки передачи конечно. Я бы активировал бит четности UART, так как µC поддерживает его аппаратно, и он должен быть очень быстрым, но все же немного небезопасным, если из-за шума изменяются только правильные биты...
Вы могли бы хотеть искать Кодирование Хемминга . Он будет принимать до 16 команд (4 бита) и систематически расширять их до 7 бит (которые можно передавать по стандартному UART). Вы можете исправить любую одиночную битовую ошибку или определить, были ли ошибочно приняты какие-либо два бита.
1) 7 бит + бит четности - это в одну сторону и это просто. Он не поймает все возможные ошибки, но поймает многие. 2) Более надежный метод - отправить два байта, первый с фактической командой, а второй с «не» первой команды. 3) Еще лучше послать байт «пришедшая команда», за которым следует команда, за которой следует дополнение команды, за которым следует «байт конца команды». Байты «приход команды» и «конец команды» должны быть выбраны так, чтобы не накладываться ни на один из байтов команды и команды дополнения.
так как вам нужно всего 10 команд кода Хэмминга + бит четности, это не проблема.
Не знал о Хэмминге, спасибо, звучит многообещающе!
Если вам нужно всего 10 команд, вы можете поместить две копии в каждый байт (для избыточности) плюс биты четности. Или, поскольку у вас есть пространство символов из 256 символов, а нужно только 10, вы можете просто выбрать максимально разные символы (все символы отличаются несколькими битами) или выбрать только символы с четным количеством единиц и нулей. Вам, конечно, не нужно беспокоиться об однобитовых ошибках.
На данный момент некоторые приличные мысли были вложены в форматирование данных, но вам также следует подумать о последовательности и сообщениях, которые могут быть задержаны из-за буферизации — вы можете этого не хотеть, но по умолчанию вы будете иметь это на стороне ПК. Поскольку вы упоминаете USB (предположительно UART, подключенный к USB), также подумайте о задержке, которая может привести к потенциальным проблемам, связанным с (повторным) перечислением.
Коды Хэмминга имеют ограниченную полезность для связи UART, учитывая, что сбой, возникающий непосредственно перед началом пакета, может привести к неправильному кадрированию всех последующих данных. В общем, можно также предположить, что если какая-либо часть пакета дает сбой, весь пакет следует считать бесполезным.
Возможно, стоит посмотреть, как обмениваются сообщениями SECS/GEM между оборудованием. Вы могли бы украсть некоторые идеи оттуда. Они довольно серьезно относятся к управлению сообщениями и точности.

Ответы (2)

Я думаю, вам следует определить более длинные команды, включая, возможно, контрольную сумму или CRC, и дождаться ACK/NACK или состояния ошибки.

Вы можете взять примеры из простых протоколов, таких как TFTP ( RFC 1350 ) .

Для безопасного общения вы должны рассмотреть все возможные потоки к вашей линии связи. Поэтому вам необходимо определить, доступна ли система извне (системы сторонних производителей, например, беспроводная связь).

В общем, вам нужно подумать о следующих темах:

  • повторение
  • поручение
  • изменение последовательности
  • манипуляция
  • задерживать
  • вставка
  • коррупция

Стандартные меры против потоков:

  • Последовательность или временные метки
  • контроль времени
  • уникальные коды источника и назначения
  • отклик
  • процедура идентификации
  • какая-то контрольная сумма, хэш-код...
  • криптографические методы, некоторые из которых вы уже реализовали в своем простом протоколе.
Как создать безопасный протокол связи UART?
СпросиСетьПолитика конфиденциальности1y, 0v