#security #ssl #encryption
#Безопасность #ssl #шифрование
Вопрос:
Целевое оборудование — это довольно маломощный микроконтроллер (ARM Cortex-M3 с частотой 72 МГц, всего около 64 КБ SRAM и 256 КБ flash), так что здесь нужно идти по тонкой грани. На моей плате есть Ethernet, и в конечном итоге я получу LwIP (облегченный пакет TCP / IP FOSS suite), работающий на нем (в настоящее время с трудом). Однако мне также нужна какая-то сверхлегкая альтернатива SSL / TLS. Мне известно о нескольких реализациях SSL / TLS под лицензией GPL для таких микроконтроллеров, но их объем по-прежнему довольно значителен. Хотя они и вписываются, учитывая все остальное, не оставляют много места для других.
Мой трафик — это не HTTP, поэтому мне не нужно беспокоиться о HTTPS, и мое взаимодействие клиент-сервер может быть полностью проприетарным, так что нестандартное решение подойдет. Ищу предложения о том, какой может быть минималистичный, но надежный (ну, слабая безопасность бесполезна) вариант, который мне помогает —
- Зашифруйте мое сообщение (C-> S amp; S-> C)
- Выполните двустороннюю аутентификацию (C-> S amp; S-> C)
- Избегайте атак «человек посередине»
Я не смогу оптимизировать библиотеку на уровне сборки ARMv7 и, следовательно, полностью полагаться на свои навыки программирования и оптимизацию компилятора GNU-ARM. Учитывая вышеизложенное, есть какие-либо указания на то, какие варианты могут быть лучшими?
Комментарии:
1. Возможно, вы захотите задать этот вопрос на security.stackexchange.com тоже.
2. спасибо @bavarious. Обязательно воспользуюсь вашим советом и тоже опубликую там.
3. @bavarious. ваше предложение действительно окупилось. там также есть несколько отличных ответов в дополнение к приведенным здесь. security.stackexchange.com/questions/3204 /…
4. Отлично. Есть также предложение Area 51 для сайта Stack Exchange, ориентированного на криптографию, но на нем пока собралось не так много преданных пользователей, так что на данный момент безопасность. SE, похоже, является лучшим местом для ответов на эти вопросы.
Ответ №1:
Если какая-либо из этих небольших реализаций TLS позволит вам отключить все функциональные возможности X.509 и ASN.1 и просто использовать TLS с предварительно разделенными ключами, у вас будет довольно маленький объем. Это потому, что используются только симметричные шифры и хэши.
Комментарии:
1. Спасибо @Nikos, звучит как отличная идея попробовать. Отбросив все претензии на то, что я много знаю о безопасности / криптографии, могу я спросить, поскольку они этот механизм по большому счету не используют? Существуют ли какие-либо врожденные недостатки при использовании предварительно разделенных ключей и использовании симметричных шифров / хэшей? В любом случае, у меня есть отличная зацепка, и я, безусловно, продолжу это исследование.
2. @mike насколько я знаю, у них нет недостатков, и они являются стандартом, предложенным IETF . Однако вам следует знать, что «высокопроизводительные» наборы шифров TLS, такие как обычные PSK и RSA, которые не включают обмен ключами Диффи-Хеллмана, не обеспечивают идеальной прямой секретности. Проще говоря, если кто-то украдет ключ, он сможет расшифровать все прошлые сеансы.
Ответ №2:
Есть CurveCP. Он предназначен для полной замены SSL.
Это довольно новое решение, которое все еще находится в стадии разработки, но его автор является известным экспертом в этой области и тщательно работал над ним в течение последнего десятилетия. В нее было вложено много тщательных исследований и разработок.
Ответ №3:
Моей немедленной реакцией было бы рассмотреть Kerberos. Это было тщательно изучено, поэтому шансы на серьезные дыры на данном этапе довольно невелики. В то же время он довольно минималистичен, поэтому, если вы не ограничите то, что вам нужно делать, вы, вероятно, не сможете использовать что-либо намного более облегченное без ущерба для безопасности.
Если это все еще слишком сложно для ваших целей, вам, вероятно, потребуется наложить некоторые ограничения на то, что вы хотите сделать.
Комментарии:
1. @джерри-коффин, спасибо за альтернативу. Прочитайте страницу Kerberos в Википедии, а также ссылку MIT. Это выглядит как реальная возможность, хотя мне еще предстоит найти реализацию для Cortex-M3. Обязательно последую этому примеру. Мое взаимодействие клиент-сервер основано на простом двоичном протоколе на основе TCP.
2. Kerberos — это не стек шифрования / дешифрования, он служит для разных очень сложных (и требующих много памяти и процессора целей), следовательно, он не будет fir для этой задачи
Ответ №4:
Возможно, вам стоит взглянуть на MST (минимальный безопасный транспорт) https://github.com/DiplIngFrankGerlach/MST .
Он обеспечивает те же гарантии безопасности, что и TLS, но требует предварительного общего ключа. Кроме того, он очень мал (менее 1000 LoC, без AES) и поэтому может быть легко просмотрен экспертом.
Ответ №5:
Я знаю, что вариант ответа появится примерно через два года, пока… «Объем памяти PolarSSL может достигать 30 КБ и в среднем составлять менее 110 КБ».https://polarssl.org/features