[denyslb 0]

Генерация ключа:

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 5]

Денис, Вы сами подумайте, что и от кого надо защищать.

Пока не очень понятно, что у Вас хранится, как передаётся и проч.

 

Предположим, что методом прямого перебора сломать это изделие не получится.

Я крипто-дилетант, но искренне уверен, что AES128 достаточно надёжен (т.е. квантовых компьютеров в обозримом будущем не появится; майнеры разумной стоимости за разумное время 128 бит не переберут никак).

 

Т.е., предполагаем, что хакер каким-то образом получил доступ к содержимому памяти контроллера. Осталось малое - подобрать пользовательский пароль (сколько байт?), и всё - искомый plaintext у нас в кармане (мы ведь его прятали?).

Насколько это реально, не знаю. Как-то интересовался темой "прочитать залоченный контроллер", но никого, внушающего доверие, не нашёл... Зато слышал много рассказов (и здесь в т.ч.) в духе "друг брата мужа сестры сам так делал...".

[denyslb 0]

Денис, Вы сами подумайте, что и от кого надо защищать.

Пока не очень понятно, что у Вас хранится, как передаётся и проч.

 

Предположим, что методом прямого перебора сломать это изделие не получится.

Я крипто-дилетант, но искренне уверен, что 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]

Если же с бытовой точки зрения, при упаковывании больших потоков информации нужно добавить key meshing. Но в целом ваш подход без определения модели противника, стоимости информации, объемов инфы, процедуры смены ключей при их компрометации - глубоко неправильный. На таком уровне любой современный алгоритм - достаточно хороший. Если есть возможность лучше возьмите openssl и сделайте не нём, это будет лучше чем писать самому.

[denyslb 0]

Если же с бытовой точки зрения, при упаковывании больших потоков информации нужно добавить 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 нерасшифрованным до момента когда доступ на сервера отзовут (обычно сутки-двое).

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