Comments 48
И какова скорость работы такого диска?
Что будет с данными, если ваше чудо устройство вдруг накроется медным тазом? То же что и с криптокошельками? Деньги есть, но доступа до них нету? ))))
скорость до 18мб/с
для нужд восстановления ключей генерируется seed фраза на 24 слова. Имея фразу, вы сможете восстановить ключи в любом другом АШ
да, так же как с криптокошельками, можно инициализировать следующую копию устройства и работать с данными через него. но предыдущее устройство всё ещё может быть восстановлено злодеями.
Usb full speed это не 18 , а 12 мегабит в секунду. В теории. И это очень медленно. Возможно автор имел в виду usb 2.0 high speed - это уже 480 мегабит в секунду, но не у всех stm32 (почти ни у кого) есть для них PHY. И да, в такой конфигурации stm- ка тут лишняя, достаточно fpga с софт процессором и флешем на борту и какой нибудь usb2.0 high speed controller, например cy7c68013a. Или usb 3300 ulpi. Или fpga лишняя ,достаточно stm32h7 или stm32f7
Контроллеры usb 3.0 пока неоправданно дороги.
Нет, именно фулспид. Причина проста - зашифровать поток в 480 Мб несколько сложнее, чем в 12 Мб :) Переход на хай спид потребует установки более мощной плисины, увеличения габаритов девайса, потребления, цены... Сейчас всё очень компактно и дёшево (около 40 баксов с платой). Я пока не вижу способов сделать быстро AND дёшево, хотя необходимость ускоряться понимаю и пишу об этом в статье.
СТМ тут нужна для реализации интерфейса с человеком, второстепенных функций, плюс на ней реализован ШИМ контроллер питания из АЦП, ШИМа и DMA :) ПЛИС полностью занята шифрованием потока. Такой симбиоз.
Также помним, что этот АШ шифрует не весь трафик, а только связанный с хранилищем. Это не реалтайм трафик и, по большому счёту, не важно, синхронизируется изменённый файл за 2 секунды или за 20. По крайней мере, я когда путешествию по "развитым" странам, там редко больше 5 Мбит интернет бывает сам по себе и АШ на этом фоне совершенно не тормозит процесс.
Из коммента : Нет, именно фулспид. ... и, по большому счёту, не важно, синхронизируется изменённый файл за 2 секунды или за 20.
Из статьи: Перевести АШ на USB 3.0, т.к. в локальных сетях ограничения скорости 2.0 уже вполне заметны.
Вы непоследовательны. Может для начала usb2 high speed реализуете? STM - ка справится с обработкой такого потока.
Не уверен что для перехода на USB3.0 необходимо непременно пройти через 2.0 хайспид, ну да ладно.
Поток СТМ пропустит, а вот зашифровать - врядли. И не забываем про стоимость решения.
И не забываем про стоимость решения.
Ну давайте вспомним про стоимость. Сколько стоит USB3 контроллер ?
Ещё раз: с шифрованием потока хайспида или 3,0 ни один СТМ контроллер не справится!
Ежели мы примем этот очевидный факт, и смиримся с установкой более мощной FPGA, то решений довольно много. Я планировал скрестить копеечный TUSB9261 с физическим или эмулируемым SATA в плисине. Сата отжирает меньше лутов, хотя забубенить сразу USB3.0 модуль тоже, часто, возможно. И избавиться от МК вовсе.
Ещё раз: с шифрованием потока хайспида или 3,0 ни один СТМ контроллер не справится!
Я нигде не утверждал что CTM32 справится с потоком usb 3.0. И рекомендовал USB 2.0 high speed.
копеечный TUSB9261
Ну не такой уж и копеечный, их и за $10 уже нигде нет.
забубенить сразу USB3.0 модуль тоже
Это как ?
Сата отжирает меньше лутов
Меньше чем что? Ее не так просто написать и у нее вроде непростые требования к IO.
И избавиться от МК вовсе.
Я это тоже предлагал. Но Вам нужна FPGA с флешкой на борту чипа(например Altera серии MAX) и выбор очень узок. Наружную флешку легко прочитать
Там же сказали, recovery phrase. Правда, как её использовать - вопрос не расскрыт.
Если крипта есть, а доступа нет, это означает что пользователь - олень. И это единственный вывод, который можно сделать из данной ситуации. У понимающего технологию юзера доступ к крипте не утратится.
меня очень смущает процесс ввода секрета. Очень, очень неудобно.
А в чем смысл шифровать данные на аппаратном ключе ?
Чем плох традиционный способ с хранением а АК ключевой пары асимметричного шифра и генерация ключей для симметричного алгоритма на АК.
А уже шифрование данных симметричным алгоритмом - на хост-системе. Это и упрощает как реализацию АК (чем проще, тем сложнее накосячить) и снимает вопросы со скоростью. Ну и готовых решений на рынке масса.
Опасения компрометации симметричного ключа? Так данные, шифруемые этим ключом, и так доступны на хост системе открытым текстом.
Ничего не понял...
Стандартная схема, это как раз обмен симметричными ключами через ассиметричный шифр (тот же DH).
Каким образом вы вычислите ключ, имея открытый пакет и зашифрованный (даже без соли) - тоже не совсем понятно. Почитайте про эллиптическую криптографию и как устроен биткойн, например...
Вам не кажется странным, что ничего не поняли вы, а читать вы отправляете меня ? )
Стандартная схема шифрования больших объемов данных асимметричной криптографией - сгенерировать случайный ключ для симметричного алгоритма, зашифровать большой объем данных им, а сам этот ключ зашифровать асимметричным алгоритмом и положить рядом с зашифрованными данными.
И в аппаратные токены убирают именно закрытый ключ от асимметрии и все операции с ним. Ну и rng тоже можно в него же засунуть.
"Работает АШ довольно стандартно – приватные ключи генерируются в нём рандомно.." - мне кажется, не поняли таки вы. И леджер с биткойном упомянут тоже не просто так - те же пара приватных и паблик ключей. И описываете вы ровно ту же систему, что и я. Только я описал условный алгоритм Телеграмма с обменом ключами через DH, а у вас она ложится рядом с данными.
А почему в ключе? По той же причине, по которой это делает в ключе Леджер и Трезор.
Еще раз повторю вопрос: зачем вы шифруете данные (содержимое файлов) на вашем АШ, а не на компьютере ?
В "АШ" (в дальнейшем - токене) хранится долговременный ключ. Это может быть как закрытый ключ асимметричного алгоритма, так и ключ симметричного, но асимметрия по многим причинам удобнее. Все операции с ним проводятся только внутри токена и этот ключ токен не покидает (и не может быть извлечен) ни при каких обстоятельствах, т.к. его компрометация приводит к возможности расшифровки всех ранее зашифрованных данных.
Но шифровать данные непосредственно долговременным ключом по многим причинам не стоит. Данные шифруются симметричным алгоритмом случайно сгенерированным сессионным ключом, уникальным для каждого шифруемого файла/блока/whatever (который затем шифруется долговременным ключом и добавляется к шифрованным данным).
Компрометация сессионного ключа ведет только к возможности расшифровки данных им же зашифрованных. А к этим данным в незашифрованном виде [недоверенный] компьютер и так имеет доступ и потенциальная компрометация сессионного ключа не влияет ни на что и работу с этим сессионным ключом можно смело вести на компьютере.
Посему задача токена - шифровать* сессионные ключи. Гонять же через него сами данные - пустая трата ресурсов.
(*) а в случае асимметричного долговременного ключа по большому счету - только расшифровывать, для (за)шифрования он необязателен.
аналог Intel Management Engine для смартфонов есть? у меня не будет уверенности в отсутствии связи пока физически не выпилены все модемы и нет контроля за его прошивкой usb
Как занести на комп владельца ответную часть, способов миллион. Собственно, в статье есть ссылка как спёрли 100 битков у леджероводов - просто прислали "обновление" на почту, те и поставили.
Первые пришедшие в голову 2 вектора атаки на ваш планшет:
Пишем лог годами, сливаем за 10 сек если юзер случайно подключился к инету.
Делаем составное USB устройство и через один физический разъём и чтец, и жнец, и полный пц. И всё это одновременно. И увидеть это юзер сможет только посмотрев специально.
Samsung Knox?
АШ раз в 50 легче и меньше. Дешевле. Надёжней (просто потому что меньше деталей). Точно не имеет известных широкой общественности дыр и лишних интерфейсов.
Про отключение интерфейсов и их гарантированное пребывание в таком состоянии - ну такое... Функция вызова экстренных служб работает даже в заблокированном смартфоне, например. В нём же он прекрасно слушает микрофон.
Удобство писать софт под распространённую платформу - сомнительное преимущество для устройства шифрования. В случае "самопального" АШ (не более самопального, чем самописный софт под андроид) 99% программистов в мире остаются за бортом. И это хорошо.
Реализация быстрого шифрования в андроиде vs FPGA? Я бы поставил на FPGA в любом случае. То, что смартфон быстро крутит веб страницы и проигрывает HD видео совершенно не означает, что он сможет также быстро шифровать поток на SHA-256, например.
Точно не имеет известных широкой общественности дыр и лишних интерфейсов.
Сильное заявление. Каким образом организована защита от чтения ключа из аппаратного токена? Как защищен девайс от программного ввода пароля (таймауты на проверку?)
Как всё это защищено от атаки по побочным каналам, типа тайминг атаки или атаки с измерением потребления тока?
Есть подозрение, что безопаснее было бы вместо всего этого огорода использовать обычный TPM, а шифровать уже на процессоре, как предлагали выше.
Когда нет ОС, а весь код вы можете посмотреть в ассемблерном листинге пошагово, то делать такие заявления можно.
Если у меня в бутлодыре в switch нет case "ввести пароль программно", то хоть вы наизнанку вывернитесь, ваш запрос уйдёт в default: return false;
Если у ключа нет команды, читающей память или возвращающей Х данные, то default: return false;
Если у чипа отключены аппаратные интерфейсы, а бутлодырь не предусматривает чтения прошивки от слова вообще (вместо этого, проверка чексумм и PGP), то default: return false;
Ввод пароля с кнопок автоматически замедлен функцией антидребезга, когда на нажатие кнопки даётся не менее 25мс и столько же на отпускание. Между вводами - порядка 3 сек на расшифровку ключей паролем и проверку результата. Разумеется, после нескольких неверных вводов паузу между вводами можно искусственно увеличивать. Ничего сложного нет.
Дёргать питанием чипа в надежде поломать ключи бесполезно, там встроенный voltage monitor & аппаратный watchdog с независимым от ядра тактированием. Чип уйдёт в сброс с обнулением памяти. Смотреть потребление тоже вряд ли поможет, СТМ хоть и кортекс, но ARM, а это конвейер и потребление чипа +- ровно. Ну, можно занять его вычислением числа Пи в простоях...
Про способы вскрытия аппаратной защиты СТМ одна из последних статей https://habr.com/ru/post/596499/ Не то, чтобы она была лучшая, но общий смысл отражает - долго, дорого, муторно и не под силу гопоте. А большего я пока и не добиваюсь.
Я так и не увидел тут облака, одиночный NAS - это не облако
А что вы понимаете под облаком?
Для меня облако, это условный дропбокс. Изменил файлы на ПК1, достал эти файлы на ПК2 в другом месте. Украли ПК1, достал файлы на ПК2. Всё. Никак иначе я облака не использую.
Для специализированных задач есть специализированные решения, тот же Git или Assembla.
Облако это абстракция над аппаратными ресурсами, когда вы не видите отдельных отдельные узлы (считайте сервера), а видите пулы ресурсов (дисковое пространство, оперативную память, процессоры). Отсюда собсно и название "облако". Условный дропбокс именно так и работает, потому он и облако. Ваш один НАС конечно можно назвать облаком, но это примерно как RAID из одного диска :-)
Никто не мешает поставить 10 насов и раскидывать данные по ним, вопрос реализации. Я для себя решил, что мне удобно иметь хранилище на невыключаемом домашнем компе. И туда синхронизировать фоточки из отпуска.
Также можно поставить пожилой сервак в другом месте, напихать в него винтов и получить второй нас.
С точки зрения пользователя это будет папка на ПК, синхронизирующаяся с облаком, пользователь не видит ни NASа, ни дисков, ни веб хаба. Всё автоматически делается. Собственно, я и хотел сделать дропбокс, но шифрованный и бесплатно.
А защита данных от порчи на той стороне, это другая тема. Довольно стандартная и изученная.
…+ берутся некоторые случайные метеоданные из интернета…
Вот уж странно. А это зачем? Энтропия возрастёт? Вообще-то надо понимать, что любая такая странность трактуется не в пользу разработки, а вызывает подозрения. Особенно, когда речь идёт о генерации секретных ключей, задействованных в криптографических преобразованиях.
Да, возрастёт, т.к. метка времени генерации ключей не сохраняется и вы не сможете восстановить точку генерации, а скорость ветра в Саратове и атмосферное давление в Лисабоне - это истинный рандом. Города и факторы, понятно, выбираются случайно. Напротив, мотание мышкой довольно типично и имеет выраженные паттерны, обусловленные физиологией человека. Также не забываем, что многие пользователи отнесутся к процедуре халатно и поводят мышой туда-сюда. Это можно численно определить и заставить юзера переделать, но всё равно...
Так замечательные рассуждения. Душеспасительные. Но тут наука нужна. Колличество энтропийных бит можете оценить при таком способе генерации?
А вы можете? Давайте начнём с ваших научных рассуждений, и лишь потом перейдём к моим оправданиям.
Это ведь самое узкое место. Вы ведь специалист по аппаратной части. Так возьмите соответствующую микросхему и генерируйте энтропийные биты. Есть такие. Например, на основе измерений теплового шума и другие. Самое логичное решение в вашем случае. И это будет настоящая случайность, а не какой-нибудь ГПСЧ. Полагаю, что Вы про такие аппаратные решения должны понимать лучше других. Вот что хотелось от вас услышать, а не самоустранение от ответа на конкретный вопрос. Но, увы.
Кое-что и на Хабр про это есть https://habr.com/ru/amp/post/128666/
Название статьи: «Как работает новый генератор случайных чисел Intel».
С тех пор многое могло измениться в лучшую сторону.
Вы сами даёте ссылку на лавовую лампу, но не принимаете силу ветра в Замбии. Чем энтропия лампы отличается от энтропии планеты?
Что до "возьмите чип и поставьте", скажу неочевидную для многих вещь - чипы стоят денег. Иногда - много денег.
И если в "обычном" программировании калькулятор на гигабайт пока ещё прокатывает, и заказчику как-то можно втереть что сейчас технологии такие вот сложные, то в хардвар мире это сразу же отражается в ценнике устройства в долларах.
А некоторые генераторы ещё и подпадают под регулирование радиоактивных веществ. Или вовсе имеют экспортные ограничения.
По ГСЧ на тепловом шуме, фотонные счётчики, счётчики гамма квантов и т.п. - вы же понимаете, что к ним нужен ещё и измерительный канал? Иногда, высокого разрешения? Иногда, высокого напряжения? А это ещё единицы и десятки компонентов, иногда весьма габаритных.
Я так вижу, что нет.
Хотите подешевле? Так правильно и дешево не всегда получается сделать. Хотя на примере аппаратных кошельков, так называемых холодных (KeepKey, Trezor, и пр.), мы видим, что сделать можно и более того, можно их продавать на массовом рынке за вполне умеренные деньги и без всяких экспортных ограничений. Кстати, в KeepKey стоит специальная микросхема, которая отвечает за формирование случайных бит. Про это прямо в документации написано. Да и с габаритами вроде всё нормально. Ещё и код открытый. Так может в вашем случае дело в чём-то другом?
А про энтропию планеты — это круто, конечно. Но звучит как бред. Надеюсь, Вы понимаете, что энтропия считается по формуле Шеннона. А этот сумма произведений вероятностей на логарифм по основанию два тех же вероятностей (со знаком минус для нормировки, так как логарифм по основанию два величины меньшей единицы всегда отрицательное число). Это значит, что нужно определиться с пространством событий, задать случайную переменную и взять откуда-то эти самые вероятности, например вероятности исходов некоторых событий.
Так я увижу ваш расчёт энропии и его сравнение с лавалампой? Вы в первом сообщении очень топили за науку, но кроме оценочных суждений я пока ничего не увидел.
А с какого перепугу я должен для вас что-то рассчитывать? Это же работа, а я вас даже не знаю. Так что как-нибудь сами, сами…
Думаю, что следует закончить. Всяческих вам успехов! Путь будет тернист!
Ваш стиль "дискуссии" одна моя знакомая ёмко классифицирует как "ввязался в шибари и забыл стоп слово".
Вы вломились под статью с криками "всё фигня" и на просьбу пояснить, за неделю, смогли предоставить лишь какую-то копипасту. Хотя даже в Вики есть достаточное определение энтропии, из которого понятно почему и как мой алго работает и его корректность доказуема, даже по помянутому Шеннону. Ну да ладно, решим, что я ниасилил впаять специальный чип.
Как идея, можно шифровать и отправлять в Storj или Sia
Хм, а технологию блокчейна туда добавите? Как я понимаю, может помочь для защиты данных от изменения или ещё какого взлома.
Самодельное облако с аппаратным ключом шифрования