×

Розробка · 6 червня 2018, 19:38 1464

Valentyn Ponomarenko, Oracle

Нужна идея от криптографов

Есть два устройства обменивающиеся HASH-256 или HASH-64 между собой по радиоканалу. HASH генерируется на основе информации и шифруется ключем, который доступен только на сервере. Когда устройства обменялись HASH-ми, они их складывают во внутренний буфер устройства до момента, когда можно подключиться к серверу и отправить. Устройств может быть много.
Буфер не большой — 512K.

Теперь мне нужно как-то защитится от DoS-атаки. Скажем в сети появляется третье устройство, которое начинает генерировать пустые HASH и рассылать их в радио-канале, в результате чего на всех устройствах буфер будет заполнен такими HASH-ми до тех пор, пока они не будут переданы на сервер и там отброшены.

Мне нужна идея, как можно бы отбрасывать такие HASH на самом устройстве, тем более, что мощности там небольшие и пытаемся все сделать на контролере встроенном в bluetooth-модуль.

Теми: ідея, криптография

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

LinkedIn

Схожі топіки

Ctrl + Enter

Ctrl + Enter

Denis Suprunenko Працює в CHIPSOFT 08.06.2018 11:43

Сделайте простую аутентификацию устройств по принципу свой-чужой (security access / seed key). И только от авторизованых устройств принимайте хэши.

Відповісти

Підтримати

Михаил Кузьмин 08.06.2018 07:13

Нумеруйте (кодируйте) сообщения от каждого устройства по собственному алгоритму и в протоколе требуйте подтверждения этого кода. Если передает свой, то он сможет подтвердить. Подтверждение можно тоже закодировать..

Відповісти

Підтримати

Vsevolod Ievgiienko CEO в Prog.kiev.ua 07.06.2018 21:33

Можно ли назначить передатчикам id и хранить их на приемнике? Если да, то подскажу алгоритм :) Достаточно хранить 16-20 байт для каждого устройства

Відповісти

Підтримати

Valentyn Ponomarenko Працює в Oracle 07.06.2018 21:40

Да — конечно. ID можно сгенерировать, так и использовать какой-то ID от самого чипа прошитого производителем.

Відповісти

Підтримати

Vsevolod Ievgiienko

Vsevolod Ievgiienko CEO в Prog.kiev.ua 07.06.2018 21:47

Тогда при регистрации передатчика на приемнике надо сохранить его id и какое нибудь рэндомное значение известное обоим. Далее каждый хэш дополняем id и функцией от рандомного значения. При этом значение тоже обновляем результатом функции для последующих передач. Выходит что это значение сложно угадать, но легко проверить. В качестве функции я бы взял что-то типа хэша от предыдущего значения + текущего времени с округлегием до 10 секунд. Надеюсь идея понятна, а то с телефона пишу :)

Відповісти

Підтримати

Valentyn Ponomarenko

Valentyn Ponomarenko Працює в Oracle 07.06.2018 22:15

Не получится — устройств может быть много. Получается каждое устройство должно хранить ID всех остальных.

Выходит что это значение сложно угадать, но легко проверить.

Не понял, как вы это значение проверите на приемнике. Как уже сказала, что приемник не хранит ID всех передатчиков.

Відповісти

Підтримати

Vsevolod Ievgiienko

Олексій Пєніє 07.06.2018 23:28

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

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

Відповісти

Підтримати

Valentyn Ponomarenko

Valentyn Ponomarenko Працює в Oracle 08.06.2018 07:01

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

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

Відповісти

Підтримати

Олексій Пєніє

Олексій Пєніє 08.06.2018 14:34

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

Вплоть до того, что этот файл будет даваться в свободном или в почти свободном доступе. Фокус в том, что даже если устройств доступа изначально 1-2 в комплекте, потом можно докупить ещё.

Вы просто знаете те детали задачи, которые для вас очевидны, но здесь вы ими не поделились. В частности, каковы цели и риски.

Відповісти

Підтримати

Valentyn Ponomarenko

Олексій Пєніє 07.06.2018 23:22

Если есть что-то, известное обоим — задача выеденного яйца не стоит. Но будет как со взломом Windows 7 — якобы секретные коды BIOSа ноутбуков стали известны всем желающим банальной декомпиляцией, и мелкомягким серверам пришлось признавать легитимными все пиратские копии.

Відповісти

Підтримати

Vsevolod Ievgiienko

Andriy Tyurnikov Программирователь 07.06.2018 15:22

вам прийдется сменить концепцию для защиты от flood, навскидку можно интегрировать 3 механики
1) Неполное доверие (ключи/сертификаты) — соответственно «левое» устройство не получит доверия
2) Лимиты и TTL на инфу, рейтинговые механизмы
3) ProofOfWork :D

Відповісти

Підтримати

Олексій Пєніє 07.06.2018 19:37

Кстати, идея с неполным доверием очень даже неплоха. Дать ложно-положительный ответ, а уже потом расширять полномочия до реальных. Грубо говоря, включить «Гостя».

Но в этом случае DDOSить ещё проще, сменив вектор атаки на забивание гостями.

Відповісти

Підтримати

Andriy Tyurnikov

Valentyn Ponomarenko Працює в Oracle 07.06.2018 20:55

Можете пояснить мне идею с неполным доверием.

Відповісти

Підтримати

Олексій Пєніє

Олексій Пєніє 07.06.2018 23:17

Задача неполного доверия — это выдача формального доступа, с тем чтобы устройство перестало спамить, а считало что оно успешно залогинилось. В другом месте тут я описал аналог с презумпцией недоверия.

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

В чём прелесть формального доверия: можно бороться замедлением процесса на грани таймаута. А то и вовсе по определённым запросам просто ничего не отвечать. Это заставит взломщика понервничать и играть с таймаутами, а значит скорость DDOS упадёт очень круто.

В чём недостаток: при ошибке передачи от легального устроства ты его точно так же утопишь в формальном доверии.

В психологии это зовётся эффектом тёплой ванны. Когда вместо агрессивного отказа противнику предоставляют формальную зону комфорта, которую не захочется покидать, и за покидание которой награждают дискомфортом неопределённости. Хакеру тяжело бросить поднятую сессию где якобы уже успешно залогинился.
_____________
КСТАТИ, бан интернет-ресурсов в Украине сделали именно таким, скотским способом. Ни один провайдер не даёт отказа. Запросы просто проглатываются, и страницы со встроенными плагинами соц.сетей или Яндекса — просто зависают в ожидании. Это не случайность, психологический приём один из самых действенных.

Відповісти

Підтримати

Valentyn Ponomarenko

Vsevolod Ievgiienko CEO в Prog.kiev.ua 07.06.2018 21:52

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

Відповісти

Підтримати

Andriy Tyurnikov

Andriy Tyurnikov Программирователь 07.06.2018 23:07

Мощности способные на вычисление хэша, но не способные на аутентификацию?
O_O

Відповісти

Підтримати

Vsevolod Ievgiienko

Valentyn Ponomarenko Працює в Oracle 07.06.2018 23:51

HASH вычисляется на сервер — на самом устройстве нет смысла хранить всю информацию, в силу малого количества памяти. Ну и мощности тоже и там же вычислять HASH нет смысла, потому что это будет отражаться на энергопотреблении.

Відповісти

Підтримати

Andriy Tyurnikov

Andriy Tyurnikov Программирователь 08.06.2018 04:03

Я себе с трудом представляю систему не способную просчитать хэш в 2018 году, ну да ладно — допустим.
Если security through obscurity — вариант — то сделайте HASH с Checksum.
Чтобы несложными вычислениями можно было проверить составлен HASH доброжелателем или злоумышленником.

Відповісти

Підтримати

Valentyn Ponomarenko

Valentyn Ponomarenko Працює в Oracle 08.06.2018 04:47

Я себе с трудом представляю систему не способную просчитать хэш в 2018 году, ну да ладно — допустим.

Микросхема на базе nrf52832, там есть свой контролер, чтобы не удорожать схему мы используем его. Ну уверен, что его мощностей хватит просчитывать HASH. CHECKSUM передаем в качестве проверки, что данные не были испорченные в процессе передачи — так как радио-эфир довольно засорен.

Відповісти

Підтримати

Andriy Tyurnikov

Олексій Пєніє 07.06.2018 11:55

Есть половинчатое решение: пакетный обмен с сервером. То есть когда на проверку может лететь не один код, а сразу куча пакетом. Это снижает объём трафика и задержки на передаче, соответственно в случае DDOS будет куда сложнее заспамить устройство — оно будет достаточно быстро избавляться от мусора.

Акцент: пакет отказа сервера должен быть максимально кратким, чтобы не грузить канал. Грубо говоря, в DDOS режиме в пакете ответа должен лететь просто список отказанных хэшей, без объяснения причин. А сам режим DDOS определяется запросом от вызывающего устройства — либо оно общается полным протоколом поштучно, либо пакетным быстрым, то есть оно дёргает РАЗНЫЕ слушатели сервера. Небольшая проблема, что придётся усложнить тест, чтобы поддерживать синхронность этих методов.

Ещё акцент — одинаковые хеши. Защита от дурака, когда какой-то дятел спамит тебя одинаковыми хэшами, но очень быстро. Я считаю, тут втупую без сортировки массива нужно пробегаться по всем, что есть сейчас в обработке. И если обнаружен дубликат за очень короткий промежуток (а значит надо иметь таймстэмп последнего вызова по каждому) — такой не просто отказывать, а ещё и формировать бан-лист. Притом бан-лист обслуживать отдельно, чтобы даже после отказа сервера хэш оставался в списке некоторое время (заранее предопределено). Но не по причине отказа, а по причине спама. Почему так: чтобы случайный генератор тебе лист не переполнил. Зачем хранить таймстэмп: чтобы ты не помещал в бан-лист запросы, которые сам почему-то не смог обработать, например по причине недоступности сервака. То есть таймстэмп подскажет, какой промежуток прошёл от аналогичного запроса, и если он сильно короткий (существенно короче того что ты разрешил легальным устройствам) — это спам, а если нормальный — ты должен ответить устройству отказ с объяснением причины (или соответствующим кодом отказа).

Відповісти

Підтримати

Valentyn Ponomarenko Працює в Oracle 07.06.2018 20:55

Есть половинчатое решение: пакетный обмен с сервером. То есть когда на проверку может лететь не один код, а сразу куча пакетом. Это снижает объём трафика и задержки на передаче, соответственно в случае DDOS будет куда сложнее заспамить устройство — оно будет достаточно быстро избавляться от мусора.

Мы будет подключать устройство к телефону. И да, все передавать будет пакетом, а потому уже отравляться на сервер. На этом этапе и будет делать всю проверку скорее всего. Телефон все-таки более безопасное устройство.

Ещё акцент — одинаковые хеши. Защита от дурака, когда какой-то дятел спамит тебя одинаковыми хэшами, но очень быстро. Я считаю, тут втупую без сортировки массива нужно пробегаться по всем, что есть сейчас в обработке. И если обнаружен дубликат за очень короткий промежуток (а значит надо иметь таймстэмп последнего вызова по каждому) — такой не просто отказывать, а ещё и формировать бан-лист. Притом бан-лист обслуживать отдельно, чтобы даже после отказа сервера хэш оставался в списке некоторое время (заранее предопределено). Но не по причине отказа, а по причине спама. Почему так: чтобы случайный генератор тебе лист не переполнил. Зачем хранить таймстэмп: чтобы ты не помещал в бан-лист запросы, которые сам почему-то не смог обработать, например по причине недоступности сервака. То есть таймстэмп подскажет, какой промежуток прошёл от аналогичного запроса, и если он сильно короткий (существенно короче того что ты разрешил легальным устройствам) — это спам, а если нормальный — ты должен ответить устройству отказ с объяснением причины (или соответствующим кодом отказа).

Думаем как-то использовать идентификатор самого модуля LoRa. Скажем, чтобы спамить разными пакетами, вам либо нужно использовать несколько однородных модулей, либо думать как взломать LoRa. Пока это все на уровне идеи.

Відповісти

Підтримати

Олексій Пєніє

Олексій Пєніє 07.06.2018 23:07

Современный смартфон — это достаточно приличная вычислительная мощность, да и место под хранение файла у него имеется.

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

Відповісти

Підтримати

Valentyn Ponomarenko

Valentyn Ponomarenko Працює в Oracle 08.06.2018 07:03

Лучше выпустить супер-дёшево и быстро, а уже потом если выстрелит — допиливать безопасность.

Это кстати тоже вариант довольно не плохой :))

Відповісти

Підтримати

Олексій Пєніє

code monkey 07.06.2018 01:46

MAC (en.wikipedia.org/...ssage_authentication_code) наверное вам поможет, но точно сказать тяжело, т.к. из вашего описания не понятен протокол общения девайсов между собой и протокол взаимодействия девайсов с серверм.

Пример примитивной имплементации:

1. Устройство (D1) аутентифицируется с сервером Srv и получает секрет S.
2. На основе секрета S устройство D1 формирует ключ (K1) (en.wikipedia.org/...i/Key_derivation_function)
3. D1 использует K1 для формирования MAC M1.
4. Устройстово D1 посылает код M1 (в вашем описании это HASH) устройству D2.
5. Принимающие устройство D2 повторяет шаги 1-2, знает ключ K1 и может валидировать сообщение M1.
6. Атакующее устройстово (A), не может аутентифицироваться с сервером Srv, соовественно не имеет ключ K1; сообщения от такого устройства не будут валидированны D2.

Мне нужна идея, как можно бы отбрасывать такие HASH на самом устройстве

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

Відповісти

Підтримати

Valentyn Ponomarenko Працює в Oracle 07.06.2018 01:53

вашего описания не понятен протокол общения девайсов между собой и протокол взаимодействия девайсов с серверм.

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

Между устройством и клиентов обычный BLE 4.0. Т.е. между устройством и сервером, не сложно. Общение через обычный телефон, а потом через интернет — и тут уже все секьюрно через SSL.

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

Я думаю, что нужно при обмене HASH применить ассиметричное шифрование.

Відповісти

Підтримати

code monkey 07.06.2018 02:08

какой-то свой проток обмена

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

Відповісти

Підтримати

Valentyn Ponomarenko

Valentyn Ponomarenko Працює в Oracle 07.06.2018 04:29

Если HASH уже был получен и есть в базе, то мы отбрасывает этот HASH. Но понятно, что можно пойти другим путем и просто собирать все HASH их сети и потому зафтулдить эфир уже существующими HASH. Понятно, что их должно быть достаточно много. НА 512kb при HASH-64 = 8192. Но в целом вы правы — это еще одна проблема.

Відповісти

Підтримати

Tymchyshyn Vitalii Researcher 07.06.2018 00:14

Задача виглядає цікаво, але інформації явно мало.

HASH генерируется на основе информации

Якої інформації? Ну нехай це буде файл. Він є тільки на одному приладі? На приладі і на сервері? На двох приладах? На двох приладах і сервері? Хай навіть без шифрування, цей хеш хоч чимось відрізняється від випадкового набору символів? Як я це можу перевірити?

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

Як прилад може зашифрувати щось ключем, який є тільки на сервері? Чи це публічний ключ і він є у всіх? Чи це ключ спеціально згенерований для даного приладу?

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

Для чого приладу-1 хеш інформації, яка є на приладі-2? А прилад-2 сам свій хеш відправити на сервер не може? Для чого відправляти хеш чужої інформації на сервер?
Версія tl;dr: що взагалі відбувається? :)
Якщо можна, додайте, будь ласка, апдейт з більшою кількістю деталей. Я не знаю як там всілякі гуру криптографії, може їм і так все ясно, але якщо додасте трохи пояснень «на пальцях», то може і хтось з неекспертів яку добру ідею підкине.

Відповісти

Підтримати

Valentyn Ponomarenko Працює в Oracle 07.06.2018 00:45

Якої інформації? Ну нехай це буде файл.

На базе текста — тут уже не важно какого, чтобы не хранить информацию на самих устройствах как в силу безопасности, так и в силу размера — разумнее просто зашифровать текст в виде HASH. Хеш будет уникальным всегда в рамках — пользователь + текст.

Він є тільки на одному приладі? На приладі і на сервері?

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

На двох приладах? На двох приладах і сервері?

Есть на на сервера и на устройствах, но как я сказал выше каждое устройство обладает своим уникальным набором HASH-ей.

Хай навіть без шифрування, цей хеш хоч чимось відрізняється від випадкового набору символів? Як я це можу перевірити?
В этом и есть вся проблема, что нужно какое-то правило, чтобы генерировать HASH таким образом или точнее, зашить в HASH какие-то данные, чтобы можно было скажет с какой-то долей вероятности отбросить HASH, который был сгенерировать вне системы. Второй момент алгоритм должен быть не такой сложный, потому что это все-таки электроника и садить батарею тоже не хочется. Тут мы думаем — что возможно просто делать чистку буфера с определенной периодичностью.

Як прилад може зашифрувати щось ключем, який є тільки на сервері? Чи це публічний ключ і він є у всіх? Чи це ключ спеціально згенерований для даного приладу?

Я тоже думал, что возможно нужен публичный ключ и приватный. Пока мы на этапе дизайна, поэтому нет выбранного алгоритма генерации HASH-ей.

Для чого приладу-1 хеш інформації, яка є на приладі-2?

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

А прилад-2 сам свій хеш відправити на сервер не може? Для чого відправляти хеш чужої інформації на сервер?

Может. Смотрите, нужно зафиксировать факт обмена. Скажем устройство 1 обменялось со 2, и 2 обменялось с 3. Получается, что 1 получить информацию 2, 2 получит информацию 3, но 1 не получить информацию 3, так как не 1, ни 3 не имеют HASH-ей друг друга.

Получаем вот это.

1 <—> 2 — True
2 <—> 3 — True
1 xxx 3 — False

Т.е. когда вся информация придет на сервер, можно понять кто с кем обменялся ключами.

И вот тут возникают следующий вопросы:
1. Как генерировать HASH (или ключ, ....), чтобы исключить факт DDoS атаки. Это не повлияет на работу сервера, так как на сервере нет таких HASH, но забьет буфер устройства ? И я пока хочу прояснить для себя хотя бы этот вопрос, потому что если можно отбрасывать ложные HASH, некоторые вопросы другие вопросы можно будет игнорировать.

Відповісти

Підтримати

Tymchyshyn Vitalii

Tymchyshyn Vitalii Researcher 07.06.2018 01:09

Ага... Здається, до мене починає доходити... Є якась інформація на сервері і вона належить різним приладам (такі собі права доступу). Якщо два прилади 1 і 2 обмінялись хешами, то сервер відкриє їм доступ до інформації одне одного, а представлені ними хеші будуть слугувати доказом, що вони таки бачили одне одного.
А ще таке питання, чи безпечно зберігається інформація всередині приладу? Тобто чи варто «боятися», що його розкурочать і скопіюють звідти всі дані? Якщо ні, то можна було б піти найбільш «дерев’яним шляхом» (це чисто в порядку ідей підкинути):
* зберігаємо на сервер 2 пари ключів, А і Б;
* при першій появі «на світ» прилад з’єднується з сервером (заводить там собі якісь дані, треба ж чимось ділитись), той ідентифікує, що все добре, і видає йому А та Б; далі прилад може ніколи більше не бачити сервер, уже не важливо;
* при зустрічі 2-х приладів, 1 і 2, прилад 1 генерує випадковий рядок, шифрує його А та передає приладу 2;
* прилад 2 розшифровує рядок за допомогою А, шифрує його за допомогою Б і відправляє назад приладу 1;
* прилад 1 розшифровує рядок за допомогою Б і звіряє зі своїм, якщо співпали — приладу 2 можна вірити, він дійсно «бачив сервер», якщо ні — ігнор;
* проводимо симетричну процедуру для приладу 2.

Відповісти

Підтримати

Valentyn Ponomarenko

Valentyn Ponomarenko Працює в Oracle 07.06.2018 20:47

А ще таке питання, чи безпечно зберігається інформація всередині приладу?

А что тут такого — это просто HASH. Если у вас нет доступа на сервер и при этом у вас не произошло обмена HASH, то вы не получите информацию другого человека.

обто чи варто «боятися», що його розкурочать і скопіюють звідти всі дані? Якщо ні, то можна було б піти найбільш «дерев’яним шляхом» (це чисто в порядку ідей підкинути):

Все можно разобрать. Скажем разберите iPhone — много от туда можно скопировать. Хотя там наверно все как раз и шифруется ключом.

Відповісти

Підтримати

Tymchyshyn Vitalii

Tymchyshyn Vitalii Researcher 08.06.2018 00:11

Дякую, зрозумів.
До речі, а Ви в сторону алгоритмів для цифрових підписів не дивились? (Ель-Гамалі всілякі). Щоб ще докидати варіантів можу запропонувати на їх основі таке:
(підготовка)
* кожному приладу видається його ай-ді
* на сервері розраховується хеш для файла і хеш для ай-ді приладу-власника
* все це підписується цифровим підписом (обидва хеші разом)
* підписані хеші разом з ключем для перевірки видаються приладам і ті їх запам’ятовують
(робота, тільки через захищений протокол)
* прилад (1) генерує випадковий набір символів і передає їх (2)
* прилад (2) передає приладу (1) підписані хеші, свій ай-ді та отриманий випадковий набір
* прилад (1) перевіряє підпис (так відкидається все, що не було згенеровано на сервері)
* прилад (1) перевіряє випадковий набір (так відкидається «реплей» по записаному з ефіру)
* прилад (1) хешує отриманий ай-ді і звіряє з підписаним хешем (так відкидаються «фейкові» прилади)

Відповісти

Підтримати

Valentyn Ponomarenko

Tymchyshyn Vitalii Researcher 07.06.2018 01:53

Хочу підкинути ще одну ідею, але тут треба все одно деталі у спеціалістів уточнювати. Приблизно така:
* Вибираємо асиметричний алгоритм шифрування, в якому важко вичислити відкритий ключ по закритому;
* генеруємо пару ключів для шифрування (Ш) і дешифрування (Д);
* для даних кожного приладу на сервері генеруємо якийсь ай-ді, чи хеш, не важливо;
* додаємо до нього контрольний набір символів, нехай «ЗгенерованоСервером», плюс сіль і все що треба;
* шифруємо їх всіх ключем (Ш), отримуємо якійсь рядки;
* кожному приладу видаємо його рядки та ключ дешифрування (Д);
* при обміні даними прилад 1 приймає рядок від приладу 2, дешифрує його за допомогою (Д) і перевіряє, чи є там «ЗгенерованоСервером»; якщо ні — ігнор; (обмін бажано теж через систему публічний-приватний ключ, але вже самого приладу, щоб не було небезпеки перехоплення даних і присвоєння собі)

Відповісти

Підтримати

Valentyn Ponomarenko

Олексій Пєніє 06.06.2018 20:50

Сами же понимаете, что в этой постановке задача неразрешима. Если это третье устройство может генерировать себе случайный идентификатор, то иначе как опознаванием его по физическим параметрам — дела не будет. То есть нужно менять сам алгоритм таким образом, чтобы в случае DDOS (либо всегда) он усложнялся, и помимо обмена хэшами шла проверка, отвечает ли устройство, которое запустило хэш. В этом случае канал всё так же DDOSится, но не устройства.

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

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

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

Можно добавить в протокольную часть неочевидный алгоритм. А именно — чтобы какой-то кусок протокола давал вроде бы незначительные данные, но подсказывающие устройству более длительное время жизни ключей. То есть когда авторизующее устройство входит в режим защиты от DDOS, оно посылает сигнал отказа всякий раз. Но чтобы в этом сигнале отказа содержался якобы мусор, который пишется в массив байт, будучи нераспознанным, а потом поверх него вносятся свежие данные и шлётся повторный запрос. Фокус в том, что неочевидный кусок мусора находится по определённому смещению в массиве, и никогда явно не инициализируется. Если код при этом вручную обфусцировать, можно сильно замедлить взлом. Но против профессионала это не поможет — держа в руках живое устройство и имея доступ к каналу, достаточно быстро обнаружат несоответствие при скане. Но можно сильно усложнить задачу, добавив туда гораздо больше мусора, так чтобы реально значимый кусок было сложно найти. А он, разумеется, не будет постоянным, а будет меняться раз в какое-то время случайным образом. Можно в передающем устройстве нагенерить мусор из какого-либо аналогового датчика или прослушав канал, и через XOR наложить на исходный массив. Фокус в том, чтобы «случайно» промахнуться по смещению, и ключевые данные оказались не затронуты, но выглядели всё тем же мусором.
____________
Если кратко, задача совсем не техническая. Если твои протоколы открыты, то обманывать нужно человека, а не железо. Если человек поймёт, чего хочет твоя железяка — ему труда не составит это подделать. Любые традиционные алгоритмы защиты, основанные на замедлении — сработают против тебя, поскольку замедление требует памяти, и это в аккурат усугубляет твою проблему.

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

IMHO последний вариант самый надёжный, и только он применим если речь обезопасности. Кусок постоянной NAND памяти — шутка недорогая, сами данные для него могут лежать в открытом доступе и быть частью прошивки. Либо применять изначально шифрованную NAND, но насчёт стойкости алгоритмов ничего не скажу. Однако так будет удорожание лишней NAND и вероятно более дорогим контроллером.

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

Відповісти

Підтримати

Підписатись на коментарі

Ваша пошта

Не підписуватись