Comments 56
А можно поподробнее про 56 бит, это разработка и производство без лицензии или использование?
Ии зачем там процессор мультиклет?
В РФ разрешено без лицензии производство устройств с шириной ключа не более 56 бит. Процессор Мультиклет позволяет ускорить шифрование данных.
Значит нужно дописать в минусы аппаратных средств короткий ключ (я так понимаю это ограничение ФСТЭК, найти пока не смог, но это не только для импорта устройств?)
Проводилось ли сравнение оптимальности использования мультиклета, по сравнению с другими процессорами или плис?
Ну это ограничение по закону РФ, если интересно могу выложить скриншоты. Но ограничение пока нет лицензии, а она в планах(потом AES256 и ГОСТ89 для РФ) Да на форуме multiclet.com есть обсуждение и сравнение по алгоритму ГОСТ89 с Рутокенами например(в 3-4 раза быстрее было). Есть также сравнение с процессором Интел на некоторых специальных тестах.
Интересно, а шифрование по блокноту, кусками по 56 бит подходит?
Ну и интересно, где определение криптографических средств шифрования, у нас вот многие пытаются назвать их скремблированием и ничего не лицензировать…
В законодательстве в РФ есть и исключения для устройств с шифрованием. Т.е. импорт некоторых устройств без лицензирования с алгоритмами шириной ключа 256 бит производился и производится(например процессоры Intel и другие устройства). Вопрос в том, что назвать можно как угодно, но если применены алгоритмы шифрования, то потенциально за вами могут придти).
Да я понимаю, что могут выехать, но вы оперируете фразой «алгоритм шифрования».
А там фраза — «формирование ПСП», например…
Хочется понять, в какой момент сложение по модулю 2 становится алгоритмом шифрования.
Если устройство содержит алгоритм шифрования, любой из известных, то это устройство шифрования. Лицензирование и подразумевает разрешение использование алгоритмов шифрования и производство устройств с ними, там несколько миллионов надо на всё.
Да, несколько миллионов и полгода времени минимум…
А если малоизвестный алгоритм или самопальный, на который согласен заказчик?
Там в законе же прописано какие методы шифрования попадают и какие алгоритмы, а попытаться увильнуть от законов любым способом мы не нацелены. Будет спрос на устройство, будет и лицензия.
Про вас всё понятно, стандартный алгоритм, лицензии и прочее…
Я про кого-нибудь другого, ПСП с секретным начальным заполнением >56 бит является симметричным шифром попадающим под закон?
Мое мнение, если устройство не Plug&Play(т.е. требует установленного на компьютере софта для работы с ним), то оно заведомо хуже того же TrueCrypt. Так что единственным «работающим» вариантом я считаю такие флешки с кнопками для разблокировки.
Для функционирования устройства дополнительный софт не требуется устанавливать, софт нужно поставить на свою ОС для первоначальной инициализации.
Запуск стороннего софта с флешки для ввода пин-кода и работы с защищенными данными для меня не сильно отличается по неудобствам от установки оного в систему. А как с нее загрузиться? А если не Win/MacOS/Linux?
Я так и TrueCrypt могу с флешки запускать.
Т.е. Вы считаете, что сделать два клика мышкой и ввести пин-код (около 5 секунд на всё) это очень неудобно?
Это не всегда возможно сделать в принципе. И это очень сильно урезает область применения устройства.
Получается единственный плюс Вашего устройства против флешки с truecrypt в том, что шифрование происходит в самом устройстве. Хотя кто знает, что делать если устройство откажет в неподходящий момент.
Ну в большинстве случаев это возможно сделать, напишите случаи когда это не получится сделать, мы подумаем что можно сделать.
При инициализации устройства Вы можете сделать резервную копию своих ключей, а после этого можете установить этот набор ключей на устройство. Также Вы сможете делать резервные копии зашифрованных разделов на накопителях.
Например использование такого носителя для загрузчика операционной системы
По-моему, это почти идеальный вариант использования — своя ОС, свои данные, 100% уверенность что ничто стороннее твои данные никуда не сольет.
Хотя, на вкус и цвет все фломастеры разные, для меня, например, ваше устройство(в текущем его варианте) тоже «ухищрения».
Да это без проблем вы можете сделать на нашем устройстве, подключаете флешку через key_P1 и грузитесь с открытого раздела и далее как на обычной ОС работайте, тут я не вижу сложностей.
Честно говоря, я не вижу внятного сценария применения этой штуки. Рассмотрим отдельно программные и аппаратные средства шифрования дисков:

Полностью программные (как TrueCrypt):
+ низкая стоимость (вплоть до 0)
+ нет ограниичений по используемым носителям
+ богатые сервисные возможности (администрирование, бэкапы, удаленный доступ и т.п.)

Полностью аппаратные (как DatAshur)
+ работа на любой системе
+ защита от кейлоггеров
+ защита от брутфорса
+ возможность удаления данных без компьютера

А у вас получилось «ни рыба, ни мясо». Шифрует отдельная железяка, но ключи ей передает программа. В итоге от преимуществ аппаратных шифровальщиков ничего не осталось: ключ можно перехватить программно, зашифрованный файл можно брутфорсить, просто вставить устройство в любой компьютер, как обычную флешку — не получится.
На самом деле всё не так как Вы пишете, видимо сложно объяснял.
Итак
1) К устройству можно подключать обычные флешки, SD карты — подключили SD карту и вот вам флешка
2) Устройство можно просто вставить в любой ПК
3) Мы не передаём никакие ключи, шифрование проходит на устройстве!
4) Брутфорсить AES256 сотню лет можно
5) Если данные на флешке или SD карте и ещё зашифрованы по секторам, то и целой жизни не хватит на брутфорс
6) Ну и как опция в дальнейшем — защищённое копирование с флешки на SD карту
1) Несомненно, плюс
2) А софт устанавливать нужно? А если это не разрешается? Запускать с флешки?
3) Пин в любом случае вводит пользователь, и его можно перехватить.
4, 5) Вопрос в реализации. Хранилище ключей, зашифрованное по паролю/пину — вот основная цель. Если нет защиты от вскрытия, его можно будет слить с устройства, и брутфорсить пин.
6) Возможно, полезная опция. Но куда полезней было бы копирование на другую флешку.
2) Запускаете с флешки программу в которой вводите ПИН код (софт для повседневной работы не нужно устанавливать)
3) Для защиты от перехвата есть виртуальная клавиатура, ну и есть ухищрения при передаче пин-кода по каналу USB
У нас есть идеи сделать максимально надёжной передачу ПИН кода (это будет как опция для пользователя):
а) пользователь задаёт при инициализации номера цифр которые ему необходимо ввести (перед вводом ПИН кода пользователь видит картинку из случайных цифр). Например задали цифры: первая, вторая, последняя — как результат каждый раз новое значение
б) к этому значению можно ещё сделать прибавку статическую(Пусть видим цифры 1 2 3 4 5 6 7 8, вводим в качестве ПИН кода 1+2+8 = 11, если добавить статическую прибавку, например 5, будет число 16)
в) с устройства на ПК может приходить случайная посылка и потом деформироваться
г) можно вообще картинки животных добавить как топ уровень защиты

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

4), 5) Ключи во флеш памяти процессора, устройство никакие данные по ключам не отдаёт наружу
2) Единственное возражение — нужно носить бинарники под все доступные платформы. А если на машине флешки монтируются с опцией noexec?

3) Всевозможные экранные клавиатуры — это лишь полумера. Грамотно написанный троян спокойно перехватит данные со всех HID-устройств + картинку с экрана.
Да, есть технологии, позволяющие подтвердить знание пароля, не передавая сам пароль, по принципу «запрос-ответ». Они появились почти десяток лет назад, но широкого распространения не получили. Почему? Они очень неудобны для пользователя.
2) Тогда скопировать и запустить и всё будет работать

3) Ну пускай троян перехватит какое-то число, потом ещё надо посидеть поразбираться как оно сформировано, надо много раз наперехватывать целые видео по вводу ПИН кода, тут ещё можно окно выводить в разных местах экрана. Технологии надо ещё разделить по направлению:
а) защита от подглядывания
б) защита от мониторинга канала USB
Реализация пункта б) не накладывает никаких неудобств на пользователя. Реализация а) может быть какие-то неудобства и наложит, но тут смотря что придумать, можно всё сделать просто, удобно и красиво. Если пользователь забудет вдруг свой ПИН, то на этот случай есть код разблокировки заданный заранее пользователем.
Автор подскажите, планируется поддержка MacOS — какой версии?
И можно поподробнее о совместимости для разных ОС?
Софт пишется на QT, поэтому постараемся реализовать поддержку MAC OS.
А когда будет приблизительно поддержка алгоритмов шифрования? DES 56 бит это эквивалент отсутствию шифрования.
Сейчас запущен проект www.kickstarter.com/projects/65088411/664379243?token=25b25199, там подробнее расписано как и что распланировано. В РФ для оформления лицензии нужны финансы, после приобретения будет использоваться AES256 и ГОСТ89 шириной ключа 256 бит (мы понимаем про DES и 3DES).
А что мешает зарегистрировать компанию производящую софт в другой стране и выпускать плагины с поддержкой алгоритмов шифрования? Зачем ограничиваться нашими остроумными законами?
Для кикстартера сделано(можно по ссылке на кикстартер увидеть, которая выше). Но мы нацелены и на РФ.
Я имею ввиду пусть шифрование будет плагином, который можно беспрепятственно скачать через репозиторий плагинов, а делает плагин фирма, зарегистрированная в другом государстве, в итоге никаких лицензий, и шифрование хоть завтра.
Это уже обходные пути, не думаю, что они понравятся нашим службам. Просто сложности обновить устройство немного позже никакой не будет, сначала попробовать DES, потом перейти на AES.
Как вы собираетесь ускорить CBC мультиклетом, если шифрование в нем не параллелится? Откуда будет браться IV? Как предполагается гарантировать целостность информации?
Шифрование очень хорошо параллелится на уровне инструкций, т.е. у нас параллельность не в одновременном шифровании различных блоков, а в распараллеливании шифрования одного блока. Мультиклет Р1 сформирует вектор инициализиции. Уточните вопрос про целостность информации.
Ну а это быстрее/дешевле/энергоэкономичнее плисины?
Или дорого, но быстро и экономично или дёшево, но греется сильно?
Если рассматривать непосредственно сам процессор, то алгоритмы шифрования выполняются на мультиклеточных процессорах быстрее чем на аналогах на той же частоте, разумеется в программной реализации. Процессор Р1 на 80МГц греется не сильно, Р2 будет почти в два раза меньше греться. По стоимости — около 500р за процессор. В идеале всю конструкцию на Р2 сделать и в итоге получим поддержку highspeed и следовательно демонстрацию скорости работы процессора во всей красе. Сейчас с Р1 режим fullspeed как и у продукта Миландра. Себестоимость устройства очень даже приемлемая получилась, но я не отвечаю за формирование итоговой цены. Можете написать какую цену вы считаете приемлемой для данного устройства.
Аналоги на той же частоте… А если аналоги будут работать на большей частоте?
Я врядли когда либо куплю такое устройство, мне не нужно, я truecrypt-ом если нужно воспользуюсь и в своём окружении тоже пока не вижу применений. Меня интересует вопрос с инженерной стороны, я ГОСТ и DESы на курсовой делал на ПЛИСе и прогать умею только под них, а под процессоры, темболее мультиклеточные совсем нет. Вот было бы интересно узнать сравнение вычислительных мощностей (с примерными ценами и другими важными параметрами) при реализации криптографических алгоритмов на разных платформах. А то может ну их нафиг ПЛИС, прошлый век, а стоит изучать мультиклет и внедрять его везде на работе…
Ну если вопрос ставить по работе с простыми алгоритмами, то можно и ПЛИС, но если вам нужны интерфейсы посложнее то берите Мультиклет. Программировать мультиклеточные процессоры на Си можно также как и любые другие, на ассемблере мне кажется даже проще чем другие, по-крайней мере параллелится всё аппаратно multiclet.com/community/projects/examples/wiki
Я думаю ГОСТ достаточно простой алгоритм, а интерфейсы как я понял и вы тоже реализуете на отдельной микросхеме.
Конкретную задачу можно сделать на ПЛИС быстрее, а если что-то поменялось или какие-то хитрые алгоритмы и интерфейсы задействованы, тогда лучше процессор на кристалле.
Фразу про «что-то поменялось так и не понял»…
+ уже есть ПЛИСы со встроенным процессором (хотя точнее наоборот, процессор, со встроенной ПЛИС) типа xilinx zynq, но интерфейсы думаю можно запилить и без процессора.
Процессор который внедрён в ПЛИС на той же технологии заведомо медленней.
Медленнее чего?
Можно всётаки узнать, с какой скоростью шифрует по ГОСТу ваш мультиклет, без ограничений интерфейсов?
Там какие-то абстрактные рассуждения о скорости перемножения матриц, про рутокены не нашёл (А может они в 3-4 раза дешевле?).
Цены не окончательные, на мой взгляд можно снижать прилично, тут ещё плюс, что можно работать с неограниченным количеством накопителей. Пользователь mouse производил измерения работы алгоритма ГОСТ89 и сравнивал, если интересно, то на форуме есть обзор простого теста popcnt, там тоже есть сравнение и интересные результаты с табличкой с цифрами.
Целостность информации это гарантия того что полученный текст был действительно изначально зашифрован определенным ключом, а не просто случайный мусор. AES CBC без отдельного HMAC этого не обеспечивает.

На основе чего будет сформирован вектор инициализации? Аппаратный ГСЧ?
Ну почти аппаратный ГСЧ, есть АЦП + другие методы программные для формирования случайной последовательности.
Only those users with full accounts are able to leave comments. Log in, please.