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

Question

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

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

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

Answer 1

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

Answer 2

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

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

Answer 3

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

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

Редактировать:

Видишь это ТАК что публикуйте ниже приведен список альтернатив шифрования, некоторые из которых должны достаточно хорошо работать во встроенной среде (например КриптоПП и TomCrypt - Шифрование).

Answer 4

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

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

Answer 5

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

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

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

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

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

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

Answer 6

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

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

Я предлагаю вам прочитать Bruce Schneier's материал для начала.

Answer 7

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

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