Действительно не имею, я системщик.
Я и интересовался доморощенными DoS атаками. Насколько велика вероятность того что кто то "просканит" IP и решит побаловаться?

SSL интересная штука, и на Qt это вполне реализуется (непонятно только почему Qt4 сомнительная библиотека? )? Но как реализовать это на 8 битном контроллере при 8МГц, в котором ещё 2 протокола крутится - памяти может и хватит, может даже и процессорного времени, но самому писать SSL - нереально. Вот думаю RSA прикрутить просто ради надёжности чтоли ))) . Там всё проще.

вероятность велика ровно на столько, насколько это кому-то нужно
если ваш сервер захотят получить как халявные ресурсы - то тут решение проще, закрыть всё что только можно , свой сервер вешать на нестандартные и далекие порты за 40к , которые ну очень редко просто так сканируются, да и неизвестный сервис для доморощенных ломаков не интересен потому что ломать они его пол жизни будут

а вот если вас захотят целенаправленно свалить , тот тут вам никто не поможет, в данном случае у нападающего преимущество

Сообщение отредактировал follow_me - Jun 29 2011, 18:03

На стороне сервера вам, собственно, ничего дополнительно писать не надо, просто ставите stunnel и все. На 8бит-8 МГц с ssl конечно тяжеловато будет, как впрочем RSA, плюс еще памяти минимум 64к надо. Кстати в ssl наиболее затратный по вычислениям момент это аутентификация и генерация сеансовых ключей которая происходит как-раз с помощью RSA. Но если вы в начале разработки то зачем ограничивать себя контроллером? PIC32MX695H стоит аж 8.5$ в розницу и 6.5$ в партии >1000. ssl тянет свободно. В серии STM32F103 есть контроллеры с объемом памяти 96к(в принципе можно и внешнюю память повесить, но дороже выйдет), а в 205/207 серии 128к. Тоже ssl без проблем потянут. Наконец можно подождать пока Telit свой встроенный ssl допилит.

Хорошо, сделаю вид что никто не знает, что SSL в полный рост реализован в модемах Sierra Wireless

Но вообще слухи о SSL сильно преувеличены.
Никакой RSA там не нужен ибо в модемах есть защищенный сторонний канал передачи ключей по SMS.
Во вторых самый вычислительно долгий процесс это не RSA который по ресурсам не большем чем FFT требует, а вычисление длинного простого числа для алгоритма Дифи-Хелмана. Но опять же если ключами обменялись заранее то больше ничего не надо.
Ну а сеансовое шифрование в SSL может вестись по RC4.
Кто не знает, это примитивнейшая подстановка по индексу в массиве с перестановкой в массиве.
Даже на 8-и битном проце это пара десятков тактов. Самый быстрый алгоритм шифрации из известных.
Вообщем SSL работает на 8-и битниках работает влет и никаких сверхзатрат памяти не требует.

Использую NAT - открыт один порт - тот на котором сервер весит. За 40К - спасибо за совет.




Памяти всмысле флэш? Использую мегу128 (только не надо смеяться - что познал на том и делаю- а познал только 8битки атмеловские). Стесняет то что впринципе вся переферия для контроллера подобрана и прошива уже написана(кроме шифрования - сначала оно и не предполагалось), а переходить на тотже STM32 надо время. А в конце сентября уже надо начать тестирование. Зимой хочу спрыгнуть на ARM (может на тот же STM32). Может на нём запустить RTOS со встроеной SSL?


А цена то - в 2 раза больше цены 900х

Сообщение отредактировал MKdemiurg - Jun 29 2011, 19:53

ну так вернемся к основному вопросу - каким образом SSL спасет сервис топикстартера от DoS ?

Как и говорилось раньше - он отличен для сохранения секретности но никак не для обеспечения отказоустойчивости из-за исчерпания ресурсов

есть множество грубых и примитивных атак которые реализуются в данном случае, только из-за того что злоумышленник будет сидеть с сервером и клиентами в одной,относительно небольшой, подсети (т.е. 1-10к вероятных клиентов).

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

грубо, грязно - но в данном случае чертовски эффективно и никак не защититься от такого

Мне кажется вы запутались в механизмах DoS атак.
Такие атаки страшны не на TCP и тем более IP уровнях, а страшны они на прикладном уровне где действительно идет много ресурсов на программный парсинг.
На уровне TCP аппаратура нисколько не напрягается от сплошного потока запросов. В самом напряженном случае отбой начнет давать ближайший к доморощенному хакеру роутер.
Никаких сессий на аппаратуре не возникает если приходит какой-то шальной IP пакет. Это все идет в реальном времени т.е. не создается очереди ответов даже.
Таймауты в TCP стеке практически не занимают ресурсов. Их может быть хоть миллион.
Для интереса посмотрите сколько на вашем компе существует включеных тредов и сколько ресурсов они потребляют.
А таймауты потребляют меньше чем треды на порядок.
Т.е. даже гипотетически DoS атаку из подсети провайдера один компьютер создать не может. Атакующих должно быть очень много физически и они должны свободно пропускаться на прикладной уровень, что с SSL им не удастся.

Про Sierra Wireless не знал.

На счет передачи ключей по sms... ну как бы это уже не совсем ssl получается. Причем насколько я понял стоит задача обмена между девайсом с GSM модемом и сервером подключенным не через GSM модем. На счет Дифи-Хелмана. Если мне не изменяет память то аутоидентификация производится по Дифи-Хелмана ИЛИ с помощью RSA. Так зачем использовать более затратный алгоритм?(должен правда признаться что с Дифи-Хелмана не знаком поэтому вывод о затратности сделал с ваших слов, но в любом случае его поддержка необязательна)
На счет сеансового шифрования. Ну восьмибитник, с учетом скорости GPRS, и AES потянет, но там еще надо хеш по MD5 или SHA вычислять - тоже не мед.
А насчет памяти - максимальный размер буфера 32к отсюда и затраты. Можно конечно меньше сделать, но уже отклонение от стандарта, потеря универсальности.



К сожалению RAM.

А, что собственно смешного? Нормальный контроллер. А до осени еще времени ого-го. А какя RTOS имеет встроенный RTOS? ucLinux? Ну тут уж точно до сентября не справитесь. Да и во втроенную память не вложитесь, и вообще стрельба из пушки по воробьям. Я просто прикрутил polarssl к FreeRTOS задача совершенно не сложная. Просто пишите функции sslRead/sslWrite через которые эта библиотека читает/пишет из/в канал и sslOpen/sslClose для открытия закрытия сокета и все.

С помощью RSA подписывают и расшифровывают сертификаты. Но если уж взялись расшифровывать сертификаты до должны уже прослеживать всю цепочку сетрификатов до главного авторизированого центра. А это куча запросов и обменов со сторонними серверами.
Я слабо верю, что вообще фриварные сорсы для мелких микроконтроллеров содержат движок парсинга сертификатов X.509, а значит RSA даже при желании непонятно куда там засунуть.

Меня, чтото пугает переход от 8биток на ARM. Думаю за 3 месяца не успею я основательно освоить ARM и перебить проект на него.
Решил пока протокол оставить открытым. А часть аутентификации на сервере зашифровать в RC5. Всё таки не MicroSoft - вероятность целенаправленного взлома ооочень мала - а так защита от продвинутого дурака. Хочу использовать в качестве изменяемого куска ключа для RC5 октеты динамического IP адреса. Это позволит "менять" сеансовый ключ. Или это плохая идея?

Сообщение отредактировал MKdemiurg - Jun 30 2011, 10:23

Не совсем так. С помощью RSA центр сертификации подписывает сертификаты, тем самым удостоверяя что предъявителю сертификата можно доверять, но кроме того сам сертификат представляет собой открытую часть RSA ключа предъявителя, который/которые(если идентифицируется и клиент) используется на этапе аутоидентификации и генерации сеансовых ключей.
У микроконтроллера не стоит задача работать с неопределенным числом сертификатов, поэтом все доверенные сертификаты просто хранятся в памяти. При установке соединения полученный сертификат сравнивается со списком допустимых сертификатов(тупо побайтно) и все. А дальше все как обычно.

не только ....
смотрим презенташку от Telit.

а про сиерру у них хитрый SSL: Sierra Wireless proposes the Security library for Open AT.

Т.е. так ненавязчиво... если хотите SSL то поюзайте наше Г.


Сообщение отредактировал Telit - Jun 30 2011, 10:50

Успеете никакого кардинального различия там нет. Зато отладка на arm точней говоря на cortex просто ная-ням. Брекпоинты на изменение памяти, real-tim логи прерываний и пр. вкусности заметно упрощают жизнь.

IP адрес от ведь не часто меняется, может лучше просто последний бит АЦП? Если несколько случайных бит прохешировать с обычным rand() может неплохо получится. Можете в хеш текущее значение какого нибудь таймера добавить.

О! А вот и telit. Допилили значит... Только я что-то не понял он что только ssl клиента поддерживает? сервер не?

Вообще да надо попробвать, если ещё отладочную плату купить... А вы можете посоветовать ARM с двумя-тремя uart и встроенными RTC ?




Ну была идея сделать так. Беру блок данных(32байта) в начало которого дописываю 1-2 байта(начальный вектор) от rand() и шифрую 8 байтным ключом по RC5. 4байта ключа - закрытый ключ (передаётся по закрытому каналу или просто константа) и ещё 4 байта - текущий динамический IP. На стороне сервера - IP известен - поэтому передавать его не надо. Начальный вектор дописываю в начало или конец или прячу внутри шифрованного блока. А подключиться с другого айпи, используя шифрованную посылку ЛОГа, не получиться. Даже если айпи один и тотже - посылки будут всёравно каждый раз разные. Или где то в этом есть подвох?

Сообщение отредактировал MKdemiurg - Jun 30 2011, 11:28

LPC17xx(на ссылку ругается) STMF32 выбирайте. А лучше спросите в конфе по arm. Может чего поинтересней посоветуют.




Я бы сделал так.
1. Серверу и клиенту известен некий постоянный секрет(ключ).
2. После соединения с сервером клиент передает серверу свой идентификатор.
3. Получив идентификатор сервер выбирает соответствующий ему секрет(ключ). После чего генерирует случайное число и передает его клиенту.
4. На основе этого случайного числа и известного обоим секрета клиент и сервер с помощью хеш алгоритма генерируют сеансовый ключ блочного шифра.
5. С помощью сеансового ключа клиент шифрует полученное от сервера число и передает его серверу.
6. Сервер проверяет полученное число. Таким образом происходит аутоидентификация клиента.
PS Я вообще-то не большой специалист в криптографии. Если хотите сделать что-то свое почитайте "Прикладная криптография" Брюса Шнайдера.

PSS И не забывайте при шифровании больших блоков добавлять к ним хотя-бы CRC и использовать CBC