denyslb 0 23 ноября, 2017 Опубликовано 23 ноября, 2017 · Жалоба Генерация ключа: random - IV[16] + CRYPTKEYSRC[64] юзерский пароль - PW[x] AESKEY = SHA512(CRYPTKEYSRC+PW) ну и соотвественно CIPHERTEXT = aescrypt(PLAINTEXT, IV... в plaintext есть CRC для проверки валидности расшифрованных данных Соответственно на устройстве храню: CRYPTKEYSRC[64] + IV[16] + CIPHERTEXT расшифровка по тому же алгоритму, с помощью смешивания CRYPTKEYSRC+PW и хеширования - получаем ключ для AES дешифруем, проверяем CRC plaintext юзеру не показываем, это секретные части RSA ключа, просто код возврата - расшифровался ключ или нет (много итераций делать не могу, даже sha512 считается долго, и памяти тоже впритык) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 23 ноября, 2017 Опубликовано 23 ноября, 2017 · Жалоба Денис, Вы сами подумайте, что и от кого надо защищать. Пока не очень понятно, что у Вас хранится, как передаётся и проч. Предположим, что методом прямого перебора сломать это изделие не получится. Я крипто-дилетант, но искренне уверен, что AES128 достаточно надёжен (т.е. квантовых компьютеров в обозримом будущем не появится; майнеры разумной стоимости за разумное время 128 бит не переберут никак). Т.е., предполагаем, что хакер каким-то образом получил доступ к содержимому памяти контроллера. Осталось малое - подобрать пользовательский пароль (сколько байт?), и всё - искомый plaintext у нас в кармане (мы ведь его прятали?). Насколько это реально, не знаю. Как-то интересовался темой "прочитать залоченный контроллер", но никого, внушающего доверие, не нашёл... Зато слышал много рассказов (и здесь в т.ч.) в духе "друг брата мужа сестры сам так делал...". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
denyslb 0 23 ноября, 2017 Опубликовано 23 ноября, 2017 · Жалоба Денис, Вы сами подумайте, что и от кого надо защищать. Пока не очень понятно, что у Вас хранится, как передаётся и проч. Предположим, что методом прямого перебора сломать это изделие не получится. Я крипто-дилетант, но искренне уверен, что AES128 достаточно надёжен (т.е. квантовых компьютеров в обозримом будущем не появится; майнеры разумной стоимости за разумное время 128 бит не переберут никак). Т.е., предполагаем, что хакер каким-то образом получил доступ к содержимому памяти контроллера. Осталось малое - подобрать пользовательский пароль (сколько байт?), и всё - искомый plaintext у нас в кармане (мы ведь его прятали?). Насколько это реально, не знаю. Как-то интересовался темой "прочитать залоченный контроллер", но никого, внушающего доверие, не нашёл... Зато слышал много рассказов (и здесь в т.ч.) в духе "друг брата мужа сестры сам так делал...". В plaintext хранится RSA-4096 (точнее длины и сами E,P,Q) в STM32F1. Сам контроллер дешифрует ключ, и подписывает с его помощью данные подсунутые юзером. Несомненно, если плату украдут, через некоторое время(возможно в течении 1-2 часов, уязвимостей в контроллерах хватает) зашифрованные ключи сдернут, но если юзерский пароль достаточной сложный, то перебирать пароль прийдется долго. Задачу можно чуть усложнить, залив плату эпоксидкой, я думаю пока ее уберут - это займет время. Можно еще сложнее - многослойная плата, после программирования отламываем кусок с падами программирования по перфорации, сам чип в BGA корпусе. Еще больше времени выигрываем. SHA512 сам по себе даже на 8x1080 перебирается 8624.7MH/s., можно конечно усложнить и сделать как в PBDKF несколько оборотов, но даже так,к примеру на 1GH/s это около 60 часов на слабенький 8 символьный alphanumeric с разным регистром, а вот если добавить спецсимволы - 83 дня, чего в принципе достаточно, чтобы сообщить о краже и сменить этот RSA ключик. Задача еще усложняется тем, что кроме перебора хеша надо дешифровать кусок данных и проверить его на валидность, это уже надо попотеть, чтоб спараллелить и скрипт-кидди уже не смогут затолкать в какойнить готовенький hashcat. В моем случае предполагается защита от "хакеров" не обладающих значительными ресурсами. Да, кстати квантовые компы ухудшают AES, который является симметричным крипто - лишь на порядок. Это много, но не фатально. А вот RSA с ними станет бесполезен, как и EC. А как ломать STM32F0 и выдергивать из них прошивку, вот реальные данные: https://www.aisec.fraunhofer.de/content/dam...r-obermaier.pdf Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kabdim 0 24 ноября, 2017 Опубликовано 24 ноября, 2017 · Жалоба Если же с бытовой точки зрения, при упаковывании больших потоков информации нужно добавить key meshing. Но в целом ваш подход без определения модели противника, стоимости информации, объемов инфы, процедуры смены ключей при их компрометации - глубоко неправильный. На таком уровне любой современный алгоритм - достаточно хороший. Если есть возможность лучше возьмите openssl и сделайте не нём, это будет лучше чем писать самому. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
denyslb 0 24 ноября, 2017 Опубликовано 24 ноября, 2017 · Жалоба Если же с бытовой точки зрения, при упаковывании больших потоков информации нужно добавить key meshing. Но в целом ваш подход без определения модели противника, стоимости информации, объемов инфы, процедуры смены ключей при их компрометации - глубоко неправильный. На таком уровне любой современный алгоритм - достаточно хороший. Если есть возможность лучше возьмите openssl и сделайте не нём, это будет лучше чем писать самому. openssl в stm32, вы пошутили? :) Кстати именно openssl, даже не в embedded я бы не особо доверял(особенно высокоуровневым фунцкиям, где могут быть сюрпризы типа heartbleed), кроме недостатка в виде безумного API, судя по новостям у него очень плохо в последнее время с верификацией нового кода, я предпочту его форки. Уточню, это брелок для хранения ssh ключей на stm32f103, проект опенсорс. Буду использовать и для своих целей, первую версию - для некритических задач. Основа крипто в брелке у меня на аналоге, mbedtls, который более дружен с embedded. Причем тут key meshing - не совсем понял, у меня создается ключ для AES256 с помощью SHA512, смешивая рандомную строку с паролем, по сути рандомная строка работает как salt, затем этим AES256 дешифруем ключ RSA(до 4096 байт включительно) размером в ~527 байт, хранящийся на внутренней флеше. Насколько я знаю, в данном случае допустим банальный CBC, т.к. ни ciphertext, ни plaintext атакующий ни модифицировать не может, как и перехватить данные и проанализировать, все происходит внутри чипа. А вот украсть брелок и сдернуть прошивку - вполне. Против всяких подслушек по питанию я пока защищаться не буду, т.к. во первых маловероятно, что кто-то воткнет мне такое в комп, чтоб я этого не заметил, и поначалу задачи будет выполнять распространенная платка за $2, а для защиты от атак по питанию и EMI надо разрабатывать плату с нуля. Модель противника - написана выше, уточню - это посторонний человек который может украсть брелок, без огромного финансирования(т.е. кластеры и железки типа 8x1080, электронный микроскоп и т.п. ему наврядли доступны), и задача сохранить ciphertext нерасшифрованным до момента когда доступ на сервера отзовут (обычно сутки-двое). Стоимость информации обычно мала, сама информация существенной стоимости не имеет, а вот возможные деструктивные действия с помощью ключей - уже хуже. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться