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

8

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

Обмен должен идти так:

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

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

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

microcontroller c embedded uart JavaForStarters
источник
1
Возможно, вы захотите рассмотреть мой вопрос и очень хорошие ответы на него.
Евгений Ш.
1
Под «более безопасным» я понимаю, что вы имеете в виду менее подверженную ошибкам передачи, не добавляющую шифрование и т. Д., Чтобы противостоять прослушиванию, а что нет. Даже это довольно обширное поле: en.wikipedia.org/wiki/Error_detection_and_correction
Fizz,
2
Возможно, вы захотите посмотреть кодирование Хемминга . Он будет принимать до 16 команд (4 бита) и систематически расширять их до 7 бит (которые могут передаваться по стандартному UART). Вы можете исправить любую ошибку в одном бите или определить, были ли какие-либо два бита получены неверно.
Neil_UK
2
1) 7 бит + бит четности - это один способ, и это просто. Это не поймает все возможные ошибки, но поймает много. 2) Более надежный метод - отправить два байта, сначала с фактической командой, а затем с «не» первой команды. 3) Еще лучше отправлять байт «команда приходит», затем команду, после чего следует комплимент команды, а затем байт «конец команды». Байты 'приходящие команды' и 'конец команды' должны быть выбраны так, чтобы они не перекрывались ни с одним из байтов команды и команды комплимента
user3629249
1
Если вам нужно всего 10 команд, вы можете разместить по две копии в каждом байте (для избыточности) плюс биты четности. Или, поскольку у вас есть пространство символов из 256 символов и вам нужно только 10, вы можете просто выбрать максимально разные символы (все символы различаются по нескольким битам) или выбрать только символы с четным числом единиц и нулей. Вам, конечно, не нужно беспокоиться об ошибках в одном бите.
Mkeith

Ответы:

1

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

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

похлопывание
источник
1

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

В целом вы должны думать о следующих темах:

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

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

  • Последовательность или метки времени
  • контроль времени
  • уникальные коды источника и назначения
  • ответ
  • идентификационная процедура
  • какая-то контрольная сумма, хэш-код ...
  • методы крипрографии, некоторые из которых вы уже реализовали с помощью простого протокола.
user2572309
источник