Исследователи обнаружили, что происходит утечка перекрестных помех внутри USB-концентраторов, подобно распространению воде в трубах, а значит, можно использовать соседние порты на USB-концентраторе для злоумышленного хищения данных.
Я так понимаю это оно самое. Фактически атака была проведена на USB1.1 LS/FS. Для атаки USB2.0 HS нужна полоса пропускания в гигагерц как минимум и ещё несколько гигагерц для сэмплирования. На сегодняшний день запихнуть в компактное USB устройство практически осциллограф с такими характеристиками нереально.
Можно, но вы уже внедрили (уровнем выше) в свой формат CRC. А раз так, то стоит это делать правильно, а иначе зачем ваш код?
… для хранения зашифрованной контрольной суммы не сложно
Нет смысла зашифровывать CRC. Проще держать CRC от зашифрованных данных. Это даже работать будет быстрее, потому, что не нужно будет ничего расшифровывать на фазе проверки.
P.S. 3 пункт дописал с задержкой, обратите внимание.
Здесь сначала идет код проверки контрольной суммы, выполняющийся при окончании чтения файла, а потом само чтение. Возможно, так писать не следует, напишите в комментариях что вы об этом думаете.
Вы считали прошивку и проверили CRC, потом вы ещё раз её считываете для записи во флеш. Но никто не может гарантировать, что второй раз вы считали с карточки то же, что и в первый раз, а контрольную сумму вы уже не проверяете. Таким образом мы имеет точно правильную прошивку на SD-карте, а что по факту попало во флеш — неизвестно.
Проблема 2:
Вы храните CRC от расшифрованной прошивки. Строго говоря, это не безопасно. Более безопасно хранить CRC от зашифрованной прошивки. Злоумышленник не должен иметь ни единой крупицы дополнительной информации о зашифрованных данных. Открытый CRC косвенно указывает на версию прошивки как минимум.
Проблема 3:
Целостность прошивки с криптографической точки зрения не обеспечивается вообще.
Можно манипулировать битиками зашифрованной прошивки, пересчитывать CRC, зашивать и смотреть
как на это реагирует ваш девайс. Зная структуру прошивки, где, например, таблицы прерываний, инициализированные данные и т.д. можно много чего наворотить, если очень захотеть.
Да даже если так. У людей уже несколько поколений мобильных телефонов, которые пылятся на полке. Их тоже в чёрный список? Или исключать из белого? Или как?
Вот ведь дичь… Ответственные системы, конечно, должны загружаться исключительно с ROM носителя. Всё в ОЗУ. Если очень надо сохранять пользовательские конфиги/параметры от вкл к вкл, то другая память, отдельная от системной с контролем целостности.
Да, конечно, хорошо, что технологии LIDAR развиваются. Но всё же в контексте робомобилей нужно стремиться развивать и использовать пассивные (неизлучающие) системы визуального обзора, проще говоря, камеры. Есть сомнения в надёжности работы лидаров, когда робомобилей будет действительно много.
Круто! Тоже когда-то хотел подобное сделать, но руки не дошли. Пару моментов:
1. Для связи телефон-телефон хорошо бы обратную связь прикрутить, тогда передача больших файлов станет более-менее реальной. Теоретически принимающий телефон может квитировать приём данных сигналя вспышкой передающему на фронтальную камеру. Вспышки и фронтальные камеры сейчас есть практически у всех.
2. Согласен, что QR код слишком избыточен. Надо свой формат метки придумать без корректирующих кодов. Контроля каждого фрейма с помощью какого-нибудь CRC будет вполне достаточно.
Ок, но всё же с головки мы получаем аналоговый сигнал, который оцифровывается в соответствии с порогами лог. единицы и нуля. Интересно было бы провести следующий эксперимент:
1. записать много раз (1000 раз) в один домен значение 0
2. однократно записать единицу в тот же домен
3. считать аналоговое значение из этого домена
4. записать ещё раз единицу
5. снова считать и сравнить значения
Но для этого потребуется сделать свой контроллер жесткого диска и много свободного времени)
Интересно, а сколько раз надо перезаписать HDD рандомными данными, чтобы метод остаточной намагниченности не дал результата? Интуитивно кажется, что немного (2-3 цикла), т.к. иначе эту технологию использовали бы для увеличения плотности записи. Кто-нибудь встречал толковые исследования?
Известно, что числа, полученные остатком от деления rand(), вообще говоря имеют плохое равномерное распределение. Хотя с другой стороны я не возьмусь утверждать, что результат сильно изменится, если взять генератор получше, но было интересно исключить этот фактор.
Ок, попробуем так. Атака заключается в том, что я могу попробовать предположить или угадать некоторую часть зашифрованного файла. Большинство файлов, которыми мы пользуемся имеют четкую структуру, заголовки, magic numbers. sim31r чуть выше предложил сжимать архиватором. Допустим, что это был rar-архив. Архив имеет в начале блок-маркер из 7 байт (0x52 0x61 0x72 0x21 0x1a 0x07 0x00). Таким образом у меня на руках первые 7 байт файла (гаммы), с которым ксорили данный архив. А дальше вы знаете. Хорошо, если поиск ограничится компьютером жертвы. Если же нет, то возможно это какая-то общеизвестная информация. Начало гаммы может дать подсказку.
Можно придумать ещё много «а если бы...», но суть в том, что у хорошего шифра сценариев атаки, кроме полного перебора быть не должно.
есть файл зашифрованный тупым ксором через текст библии (и пусть вы даже это знаете)
Вы даже не представляете насколько быстро это будет сделано. Для экономии времени достаточно взять первую строчку вашего зашифрованного контейнера и ксорить её с текстом из библии, смещаясь каждый раз на один символ. Как только в полученной строке появятся хотя бы несколько осмысленных слов, то это смещение — кандидат на ключ. В конце проверяем все смещения — кандидаты на всём контейнере и один из них полностью расшифрует ваши данные.
Понимание того, что именно перебирать сильно ускорит процесс. Например, как в Truecrypt или Veracrypt, если предположить, что контейнер шифруется 256 битным ключом, а сам этот ключ хранится в заголовке в зашифрованном виде с помощью 40-битного ключа, то атака на контейнер ничего не даст. Потому, что сначала надо быстро атаковать заголовок зашифрованный 40-битным ключом, а после этого, получив 256-битный ключ контейнера, получить доступ к данным.
Низкая энтропия. Не должно быть зависимости любого бита ключа от любого другого бита. Для примера, в тексте на русском языке чаще всего встречается буква «е». После двух гласных чаще всего будет идти согласная или пробел, редко бывает 4 согласных подряд и т.д… Любая дополнительная информация, которая поможет определить следующий бит ключа ослабляет защиту.
Если известно, что в бинарнике есть контрольная сумма, то поиск её не такая уж и сложная задача. Тем более, что она очень хорошо параллелится.
Да пожалуйста, т.е. где-то среди 2048+4 байт есть контрольная сумма. Найти её не так сложно, даже при условии, что полином заранее неизвестен.
Можно, но вы уже внедрили (уровнем выше) в свой формат CRC. А раз так, то стоит это делать правильно, а иначе зачем ваш код?
Нет смысла зашифровывать CRC. Проще держать CRC от зашифрованных данных. Это даже работать будет быстрее, потому, что не нужно будет ничего расшифровывать на фазе проверки.
P.S. 3 пункт дописал с задержкой, обратите внимание.
Вы считали прошивку и проверили CRC, потом вы ещё раз её считываете для записи во флеш. Но никто не может гарантировать, что второй раз вы считали с карточки то же, что и в первый раз, а контрольную сумму вы уже не проверяете. Таким образом мы имеет точно правильную прошивку на SD-карте, а что по факту попало во флеш — неизвестно.
Проблема 2:
Вы храните CRC от расшифрованной прошивки. Строго говоря, это не безопасно. Более безопасно хранить CRC от зашифрованной прошивки. Злоумышленник не должен иметь ни единой крупицы дополнительной информации о зашифрованных данных. Открытый CRC косвенно указывает на версию прошивки как минимум.
Проблема 3:
Целостность прошивки с криптографической точки зрения не обеспечивается вообще.
Можно манипулировать битиками зашифрованной прошивки, пересчитывать CRC, зашивать и смотреть
как на это реагирует ваш девайс. Зная структуру прошивки, где, например, таблицы прерываний, инициализированные данные и т.д. можно много чего наворотить, если очень захотеть.
1. Для связи телефон-телефон хорошо бы обратную связь прикрутить, тогда передача больших файлов станет более-менее реальной. Теоретически принимающий телефон может квитировать приём данных сигналя вспышкой передающему на фронтальную камеру. Вспышки и фронтальные камеры сейчас есть практически у всех.
2. Согласен, что QR код слишком избыточен. Надо свой формат метки придумать без корректирующих кодов. Контроля каждого фрейма с помощью какого-нибудь CRC будет вполне достаточно.
1. записать много раз (1000 раз) в один домен значение 0
2. однократно записать единицу в тот же домен
3. считать аналоговое значение из этого домена
4. записать ещё раз единицу
5. снова считать и сравнить значения
Но для этого потребуется сделать свой контроллер жесткого диска и много свободного времени)
Можно придумать ещё много «а если бы...», но суть в том, что у хорошего шифра сценариев атаки, кроме полного перебора быть не должно.