Защита сервера для GPRS приложений, Как практически реализовать? Опции

[MKdemiurg]

Написал собственный TCPшный сервак для своих устройств телеметрии. Создал протокол, как первую меру по защите от несанкционированного использования. Теперь встал вопрос: А КАК защитить его от "левых" подключений и пустых пакетов( DoS атак) ? От пустых пакетов ввёл ограничение на буффер. Когда буффер подключения забит более чем на 100 байт,а идентификаторов протокола не обнаружено , то клиент обрубается. От подключений хотел ввести таймауты. Но тут меня постиг fail. Двум устройствам, находящихся на тестировании , в тчении нескольких суток назначаются одни и теже адреса типа xxx.xxx.62.121 xxx.xxx.62.120 xxx.xxx.62.122. При этом например адрес первого устройства, уже отключившегося, даётся второму. Но адрес этот "забанен" на 5-10 минут. Столкнулся вот с такой особенностью GPRS - поэтому пишу здесь.
Кто реализовывал сам такие дела подскажите - может забить на эти защиты? Или както по другому их реализовать ? Неохото потом перегружать сервак по 10 раз на дню.

[Integral]

а фаервол по защите от атак разве не помогает?
ИР адреса у модулей динамические, поэтому любие манипуляции (бан и т.п.) не совсем подходят, чето не коректное отрубаем, модуль должен сам переподключится, в качестве идентификатора каждого модуля можно отправлять ИМЕЙ, чето такое делал, тонкости уже призабыл, передаваемые данные можно шифровать

Сообщение отредактировал Integral - Jun 29 2011, 09:28

[MKdemiurg]

Ну собственно что будет ловить фаервол? Сервер за NAT. Подключилось чтото на открытый порт, и давай швырять туда байты левые( это устранимо), а если подключиться 100-200 адресов. Будут висеть. Хотя да, можно настроить так чтобы фаервол рубал по минимальному потоку... Опять же а если GPRS глюкнет и стопор на 1 -2 минуты? Модуль то переподключиться сам - без этого никак.
Я IMEI и производственный номер устройства(моего, не модуля) использую. IMEI то можно и перешить. А комбинацию нереально "угадать".
Мне важна не безопасность данных - сниффер то негде поставить. А именно отказоустойчивость сервера.

[Integral]

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

[MKdemiurg]

Ну я не с нуля его пишу, использую Qt библиотеку от Nokia. Тоже типовое решение (просто однопоточный асинхронный без блокировок) взял и в него парсер протокола и дрова БД инкапсулировал. Вообще мои опасния направлены ,так сказать, на то, что какой нибудь "шутник" прознает порт и IP сервера( они впринципе и скрываться не будут) и начнёт его целенаправлено валить. Когда на этот сервер конектятся несколько сот устройств - это не есть гуд. Маловероятно правда, что кому то это надо....

[Integral]

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

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

Сообщение отредактировал Integral - Jun 29 2011, 11:52

[MKdemiurg]

Наверно последую вашему совету и ограничу размер пакета до 1Кб ( буффер sim900) и кол-во пакетов за сеанс подключения. Практически всё равно проверить сложно ...

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

Тогда если не ограничивать - лимитировать подключения начнёт ОСь. Вот я и хотел обойти это включением таймингов в протокол передачи. Тогда будет сложнее "имитировать". Но это же GPRS - какие уж тут тайминги.

[follow_me]

придумать правила обмена данными для отличия хороших ИР от плохих, т.е. частота посылаемых данных, длина пакетов и т.д. и т.п., если вдруг любой с ИР не соотвецтвует "нормам" - отрубаем

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

а как вам вариант такой

двухуровневая аутентификация устройств
два сервера - два порта , авторизации и коммуникационный , авторизации открыт , коммуникационный закрыт за фаерволом
первый делает хэндшейк который смогут пройти только доверенные узлы и заносит адрес в список доверенных ( или проще - фаерволом открывает порт коммуникационного сервера для данного IP)

все попытки сверх лимита(к примеру 3 неудачных хэндшейка) - пару минут чил-аут для данного IP

коммуникационный сервер просит иногда пройти повторную авторизацию

Хотя, как и у любой защиты тут тоже есть проблемы - например если злоумышленник может отправлять raw пакеты никто не мешает поменять адрес отправителя и тем самым тупо забить весь диапазон подсети , и все ваши клиенты отвалятся

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

[AlexandrY]

Кто реализовывал сам такие дела подскажите - может забить на эти защиты? Или както по другому их реализовать ? Неохото потом перегружать сервак по 10 раз на дню.

Как можно понять, вы прогадали с GPRS модемом.
Есть модемы поддерживающие SSL.
Впрочем может SSL и на QT невмоготу поднять.

Ну тогда VPN на внешнем роутере

[follow_me]

Как можно понять, вы прогадали с GPRS модемом.
Есть модемы поддерживающие SSL.
Впрочем может SSL и на QT невмоготу поднять.

Ну тогда VPN на внешнем роутере

ssl хорошо когда нужно обеспечить целостность и секретность данных , но от DoS он не спасет , если злоумышленник может слать raw пакеты то он тупо может обрывать ssl соединения, или наплодить кучу ожидающих согласования соединений

[MKdemiurg]

Как можно понять, вы прогадали с GPRS модемом.
Есть модемы поддерживающие SSL.
Впрочем может SSL и на QT невмоготу поднять.

Ну тогда VPN на внешнем роутере

Не прогадал , т.к. себестоимость готового девайса ограничена 75$. А модули с поддержкой SSL думаю стоят напорядок дороже sim900. А сейчас может ещё Sim900R появится... И зачем мне шифрование данных, если я эти данные потом в открытый доступ выкладываю? Разве что зашифровать протокол? Но его можно узнать только если залезть в девайс и снять логи c UART. И опять же даже с SSL никто не запрещает подключиться к серверу и просто висеть ничего не посылая или посылая пустые пакеты.

ssl хорошо когда нужно обеспечить целостность и секретность данных , но от DoS он не спасет , если злоумышленник может слать raw пакеты то он тупо может обрывать ssl соединения, или наплодить кучу ожидающих согласования соединений

Вот и я о том же...

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

[=F8=]

ИНХО защита от DoS это как-бы не задача вашего сервера. На этот счет пусть у админа голова болит. Ваша задача просто не допустить несанкционированных подключений и тут SSL самое оно. Кстати есть куча реализаций которые без проблем лягут на достаточно "толстый" МК: polarssl(http://polarssl.org/), matrixssl(http://www.matrixssl.org/), axTSL(http://axtls.sourceforge.net/). Кроме того операторы могут создавать закрытую сеть с отдельным apn и, при необходимости подключать в эту сеть через VPN внешние IP. В этом случае вообще ничего защищать не надо.

А модули с поддержкой SSL думаю стоят напорядок дороже sim900

Не совсем так. Телит в своих GE865/868 обещает поддержку SSL.

[Integral]

Значит задача переходит в создание собственного фаервола.
Работать должен на низкоуровневом протоколе для обеспечения безопасности (и при работе с любыми другими протоколами)
Хакеры в студию)))

[follow_me]

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

[AlexandrY]

ssl хорошо когда нужно обеспечить целостность и секретность данных , но от DoS он не спасет , если злоумышленник может слать raw пакеты то он тупо может обрывать ssl соединения, или наплодить кучу ожидающих согласования соединений

Так проблема, как понимаю, в том что автор не имеет навыков писания серьезных производительных серверов и при этом применяет сомнительную библиотеку.
У него естественная неуверенность, поэтому единственный путь это перенести аутентификацию на какие-то готовые движки, чтобы не напрягать свою самопальную реализацию прикладного протокола.
А с доморощенными DoS атаками уж как нибудь можно справится просто наращиванием производительности сервера. Главное, что этим не придется заниматься прикладной программе.

[MKdemiurg]

Так проблема, как понимаю, в том что автор не имеет навыков писания серьезных производительных серверов и при этом применяет сомнительную библиотеку.
У него естественная неуверенность, поэтому единственный путь это перенести аутентификацию на какие-то готовые движки, чтобы не напрягать свою самопальную реализацию прикладного протокола.
А с доморощенными DoS атаками уж как нибудь можно справится просто наращиванием производительности сервера. Главное, что этим не придется заниматься прикладной программе.

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

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

[follow_me]

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

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

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

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

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

[=F8=]

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

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

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

[AlexandrY]

На стороне сервера вам, собственно, ничего дополнительно писать не надо, просто ставите 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-и битниках работает влет и никаких сверхзатрат памяти не требует.

[MKdemiurg]

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

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

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

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

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

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

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

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

[follow_me]

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

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

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

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

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

[AlexandrY]

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

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

.. то они погрязнут в очередях ожидания соединения среди кучи весящих фейковых сессий.

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

[=F8=]

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

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

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

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

Памяти всмысле флэш?

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

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

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

[AlexandrY]

Если мне не изменяет память то аутоидентификация производится по Дифи-Хелмана ИЛИ с помощью RSA.

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

[MKdemiurg]

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

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

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

[=F8=]

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

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

[Telit]

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

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

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

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


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

[=F8=]

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

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

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

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

[MKdemiurg]

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

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

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

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

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

[=F8=]

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

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

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

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

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

[ArtemKAD]

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

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

[andrewlekar]

LPC17xx встроенный RTC имеет глючный. Всё равно внешний ставить придётся. Автору перебегать за 3 месяца на АРМ не советую. Зато советую не заморачиваться с шифрованием. Никому ваш сервер не нужен, чтобы его досить. Трафик шифровать тоже нет большого смысла, потому что от его перехвата никто не пострадает.

[MKdemiurg]

LPC17xx встроенный RTC имеет глючный. Всё равно внешний ставить придётся. Автору перебегать за 3 месяца на АРМ не советую.

Нашёл замену для себя STM32F107. Там тоже RTC есть. Вещь однако по цене тех же 8биток. Но там минимум полгода-год на полноценное освоение всей архитектуры. Напрягает небольшое кол-во мануалов по ARMам по сравнению с 8битками.

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

Ну на AVR шифрования я решил не делать - нет особого смысла - на 8МГц + особенности GPRS + считывание из внешней ОЗУ - это будет "ездить со скрипом". А вот в сервер я ввёл пару "ловушек" и лимитрование по времени коннекта. Не думаю, что GPRS сейчас на столько глючный, даст задержку в передаче на 1-2 минуты.

Сообщение отредактировал MKdemiurg - Jul 1 2011, 06:05

[=F8=]

LPC17xx встроенный RTC имеет глючный. Всё равно внешний ставить придётся. Автору перебегать за 3 месяца на АРМ не советую. Зато советую не заморачиваться с шифрованием. Никому ваш сервер не нужен, чтобы его досить. Трафик шифровать тоже нет большого смысла, потому что от его перехвата никто не пострадает.

А вот не разу не глючный, а очень даже правильный. По питанию жрет конечно больше чем DS1307.

Нашёл замену для себя STM32F107. Там тоже RTC есть. Вещь однако по цене тех же 8биток. Но там минимум полгода-год на полноценное освоение всей архитектуры. Напрягает небольшое кол-во мануалов по ARMам по сравнению с 8битками.

Почему меньше? Основные документы для STM32F107: описание аппаратной части(101стр.) , описание переферии и немного про ядро(1093 стр), Cortex-m3 описание ядра(380 стр). Плюс примеры работы в iar, keil, freertos.

[andrewlekar]

А вот не разу не глючный, а очень даже правильный. По питанию жрет конечно больше чем DS1307.

Я не проверял, но вот что пишет errata по этому поводу: The RTC does not work reliably within the temperature specification.

[=F8=]

Я не проверял, но вот что пишет errata по этому поводу: The RTC does not work reliably within the temperature specification.

То, что RTC могут сбоить при -40 это не совсем глюк. Кроме того в ревизии "A" проблема уже отсутствует.
PS ИМХО эти вопросы лучше обсуждать в конфе по ARM-ам. Слишком уж далеко ушили мы от GSM.

[MKdemiurg]

Такой вопросец напишу в тему, всегда ли адрес полученный по AT+CIFSR соответствует тому, который определяется на стороне сервера. Или оператор может "нашаманить" чтонибудь?

[=F8=]

Такой вопросец напишу в тему, всегда ли адрес полученный по AT+CIFSR соответствует тому, который определяется на стороне сервера. Или оператор может "нашаманить" чтонибудь?

Не всегда. Только если оператор дает "внешний" IP. В противном случае по AT+CIFSR вы получаете свой адрес во внутренней сети, а сервер видит адрес шлюза оператора.