Может ли протокол быть защищен шифрованием?

Question

Это то, чему я всегда хотел научиться. Когда я проектирую систему (программную или аппаратную), где несколько компонентов обмениваются данными друг с другом, как я могу реализовать в протоколе простое шифрование или другие функции для обеспечения некоторой базовой безопасности?

Я могу изменить протокол в любом случае, так как у меня есть низкоуровневый доступ к серии байтов, которые передаются / принимаются.

Редактировать: Меня интересует встроенное программирование, простое беспроводное шифрование для обеспечения безопасности протокола.

Answer 1

Вы говорите «базовая безопасность», но это мало что значит. Какая у вас модель угрозы? От какой атаки вы защищаетесь? Если вы передаете данные кредитной карты, вам понадобится надежное шифрование, например, RSA. Но я не могу вспомнить пример, который нуждается в "меньшей" защите. Если вы беспокоитесь о том, что хакеры могут разобрать ваш код, игра уже окончена - если это интересно или ценно, они взломают ее. Если нет, то вы потратили впустую время на его реализацию.

Answer 2

Самое простое решение на сегодняшний день - просто использовать сокет SSL вместо обычного, в стиле HTTPS / FTPS.

Нет никакой разницы в протоколе между HTTP и HTTPS, единственное отличие состоит в том, что они работают на разных портах (обычно 80 против 443), и один использует обычный сокет, а другой использует сокет с шифрованием SSL.

Answer 3

Не реализуйте базовое шифрование в смысле проектирования с нуля. ОЧЕНЬ сложно правильно реализовать шифрование.

Вместо этого сконцентрируйтесь на использовании шифрования, доступного на вашей платформе ... какая у вас платформа?

EDIT:

См. SO post для получения списка альтернатив шифрования, некоторые из которых должны хорошо работать во встроенной среде (например, CryptoPP и TomCrypt ).

Answer 4

Есть много вещей, которые необходимо учитывать при разработке защищенной системы. Просто упомянуть несколько:

• Выбор симметричных / ассиметричных схем шифрования
• Алгоритм шифрования (AES, Blowfish, DES)
• Выбор известных протоколов (например, SSL)
• Управление ключами и распределение
  • Один главный ключ (если взломан, вся система взломана)
  • Ключ на устройство (распределение ключей может быть более сложным)
  • Защита каналов распространения ключей
• Будет ли потенциальный хакер иметь легкий доступ к образцу устройства? Например. потребительский продукт, такой как X-box против коробки, запертой в телефонной станции. Защитить от взлома труднее, если у хакера есть физический доступ.
• Человеческий фактор - социальная инженерия и т. Д.
• Система защищена настолько, насколько защищено ее самое слабое звено.

Предлагаю вам прочитать материал Брюса Шнайера для начинающих.

Answer 5

Если вы занимаетесь встроенным программированием, тогда в чем проблема шифрования?

Пока вы работаете на одном процессоре, например, шифрование бесполезно.

Если вас это беспокоитмежду процессорами на устройстве шифрование может быть затруднено, поскольку у dsp не обязательно будет свободное место для любого шифрования любой сложности.

Если вы хотите быстро, то вам лучше всего подходит симметричный алгоритм, иЕсть много хороших способов, таких как Blowfish или IDEA.Вы можете хранить уникальный симметричный ключ, поэтому, если они смогут разобрать устройство, будет обнаружен только один ключ, но у каждого устройства должен быть свой собственный ключ.

Просто привяжите каждый ключ к серийному номеру, чтобыесли вы обмениваетесь данными с сервером, тогда передайте серийный номер пакета и веб-сервер сможет найти правильный симметричный ключ и быстро его расшифровать.

Если вы хотите сделать быстрое аппаратное шифрование, для моей диссертации MSEEЯ разработал семейство шифрований, использующее исчисление произвольного порядка, в котором было бы сложно определить ключ, поскольку он может быть в аппаратной схеме с использованием микрополоски, поскольку отсутствует обработка, он будет привязан непосредственно перед антенной и всем, что происходит над ней.будет зашифрован.

Answer 6

OAuth может быть интересным для вас, чтобы разрешить контроль доступа между различными API.

Если вы просто хотите зашифрованный канал данных, лучше просто наложить слой поверх вашего протокола; перейти через SSL или SSH.

Answer 7

OAuth, безусловно, является соображением. В дополнение к этому, вы можете рассмотреть WS-Security . Передавая данные через веб-службу, вы сохраняете независимость от платформы и языка, а добавление WS-Security означает, что шифрование и дешифрование находятся на прикладном уровне (сквозной). Таким образом, если вы уверены, что сообщения безопасны после того, как они покинут отправителя, вы знаете, что они будут оставаться в безопасности до тех пор, пока клиент фактически не получит сообщение (это означает, что оно не будет расшифровано сервером, а затем передано клиенту / Получатель, но ПОСЛЕ получения сообщения приложения).

Таким образом, в основном вы должны использовать OAuth для защиты / аутентификации различных приложений и WS-Security для защиты сообщений, передаваемых между ними.