Есть устройство, которое принимает некие данные и записывает их на внешнюю EEPROM, сделано оно на МК, тини2313. Задача такая, что бы никто кроме пользователя устройства не мог расшифровать эти данные (ну или подбор ключа занимал как можно больше времени), алгоритм нужен асимметричный, что бы, даже если хакер получит дамп памяти микроконтроллера, открытые ключи которые он оттуда достанет не помогли ему в расшифровке. Плюс ко всему код алгоритма не должен занимать большим, так как осталось не особо много места на МК. Сейчас занялся алгоритмом RSA, но прочитал, что ключ для стойкости должен быть не менее 1024 бит, а я не представляю где его хранить.

Годится.



Как где? Это же всего 128 байт. На выбор - либо в EEPROM проца, либо в памяти программ. С доступом по LPM.

Другое дело - скорости шифрования там очень маленькие. Не пугает?

Да не там скорости не большии данные идут порциями по 50 байт, в среднем каждые полчаса.
А что такое LPM?

LPM - ассемблерная команда (для архитектуры AVR) - загрузить (в регистр) байт из памяти программ.
Наверное имелось ввиду, что ключ должен располагаться в той области памяти программ, для которой возможно исполнение данной команды.

Да ничего не имелось. К слову пришлось. А оказалось, что топикстартер не знает, что данные можно хранить в области памяти программ. Вывод - сначала учить матчасть, потом остальное.

необходимо Вам задать это время - час? месяц? год? - а потом выбирать алгоритм.

Сильно сомневаюсь, что в Тиню влезет многознаковая арифметика

полезная книжка - Бурдаева О.В. Иванов М.А. Тетерин И.И. "Ассемблер в задачах защиты информации".

Вы много знаете алгоритмов шифрования с открытым ключем и более-менее обозримыми вычислениями? А ведь именно такая задача у топикстартера. Имеет смысл рассмотреть вопрос длинны ключа.



Спокойно Во-первых, кода там как раз немного, намного больше требуется ОЗУ.

Во-вторых, надо взять ATMega48 вместо Tiny2313 - дешевле, размер на плате даже меньше, ресурсов больше.

В-третьих, требуется произвести только 2 операции для шифрования - возведение в степень (причем, для быстродействия имеет смысл взять e=3, т.е. будет 3 умножения) и собственно остаток от деления.

Теперь посмотрим, что мы имеем по ОЗУ. Если длинна ключа n-бит, и e=3, то после возведения в степень e имеем размер буфера 3n. Для умножения вроде бы дополнительных буферов не нужно, все можно выполнить по месту. Ключ можно брать прямо по месту, на него озу тратить не надо. Кроме того, нас не интересует результат деления, а только остаток. Значит, результат у нас получится прямо в буфере после возведения в степень. Т.е. при ключе 1024 бита (128 байт) необходим буфер ОЗУ размером 128*3=384 байта. ATMega48 имеет 512 байт ОЗУ супротив 128 у Tiny2313, так что как раз войдет

Вообщем, я вроде не вижу проблем в реализации шифрования RSA с ключем длинной 1024 бита на мелком AVR.

требование алгоритма с открытым ключем неочевидно при постановке вопроса "стартпостером"

А это что?

Это и непонятно. Есть доступ к ключу - и только?

Вам пофлудить охота? Русским языком топикстартером написано, что требуется шифрование с открытым ключем. Асимметричность - это тоже один из признаков такого шифрования. Где неясность?

Что за тон? Чему обязан?

За резкий тон, конечно, прошу прощения. Я просто не совсем понимаю Ваши сомнения в том, что автору необходима криптография с открытым ключем.

Асимметричность означает, что ключ для зашифровки не подходит для расшифровки. И наоборот. Что равнозначно понятию криптографии с открытым ключом

Ассиметричный алгоритм шифрования с меньшей длиной ключа и адекватной степенью защиты - ECC (Elliptic Curve Cryptography).

P.S. Неясность в постановке задачи - где происходит расшифровка? Если в том же микроконтроллере, то ассиметричность не поможет - в памяти окажутся оба ключа - и шифрования, и дешифрования.

а что локирвание для атмеги поставлено под сомнение ?

Совершеннно верно, если хакер емеет доступ к ключю (см. постановку задачи), то , вероятно, имеется доступ и к другим элементам и этапам шифрования, в том числе, возможно и до нелинейной функции преобразования.

Давайте так. Я, конечно, не телепат, но мне кажется, что автором планируется система "даталоггер для сбора данных + Большой Брат для их выемки". Т.е. данные поступают каким-то потоком, шифруются, сохраняются во внешнюю еепром, а потом приходит дядя с ноутбуком и, вставляя шнурок, перекачивает инфу себе. В таком случае в камешке содержится только шифрование, а расшифровка на Большом Брате.



Ну смотря по стоимости логгируемой информации.



Если рассматривать все этапы, то хакер, если имеет полный доступ к оборудованию, сможет подделать данные. Но прочитать уже записанные данные он не сможет. Если такой вариант устраивает - то все пучком.

Кроме того, при более длительном размышлении я пришел к выводу, что для системы "отдельный даталоггер плюс Большой Брат для регулярного считывания" в рассматриваемом случае существует намного более простой и приницпиально нерасшифровываемый способ сохранения данных, конечно, при соблюдении некоторых условий (ну, например, защита от прослушивания коммуникации даталоггер<->Большой Брат). Однако, в этом способе хакер может добавить новые поддельные записи в лог, но не сможет изменить уже существующие, в отличии от способа с RSA.

Кстати, о RSA. Каждая запись в логе будет размером кратным длинне ключа. Не пугает?

PS Ан нет. Соврал некисло про принципиальность. Если хакер будет иметь доступ к брелку до и после записи данных в него, то можно.

Вообщем, общая стойкость такой системы сильно зависит от факторов, никак не связанных с выбором метода шифрования. Надо рассматривать стойкость системы в общем. А для этого нужно намного больше подробностей от автора.

Да всё именно так, приходит человек и по RS232 скачивает сохранённую информацию.
Про время для подборки ключа, ну хотя бы год, после эта информации будет уже не актуальна.
Советовали, на мегу перейти, это конечно не сложно, но не хотелось бы так, как уже всё собрано и отлажено на тиньке, осталось только функцию шифрования сделать, может не RSA? А что ни будь попроще, вот только что?
Про лок МК, насколько знаю, защита снимается, если нужно, а так как информация представляет коммерческий интерес, то это не остановит злоумышленника, ещё думал, чем ни будь плату залить, что бы к МК, доступ ни как не получить но вот материала пока не нашел!

А нет случайно толковых примеров на С++, или описания алгоритма, а то чего то ни чего толкового не могу найти, кроме как учебников в 300 стр.

Вы бы сначала определились, страшно Вам или нет, если хакер сможет подделывать записи в логе?

Нет, он может изменять, их удалять, подставлять, да что угодно делать это не страшно, главное что бы он не смог прочитать зашифрованные данные!

А зачем? В начале лога пишется и шифруется RSA случайный "сеансовый" ключ для скажем AES-256, им и шифруются данные. Если из-за потери питания симметричный ключ теряется - генерируется заново новый, и пишется в поток с соответствующим маркером. Правда все это в тиню точно не влезет

http://en.wikipedia.org/wiki/Elliptic_curve_cryptography

Да уж там по русски ничего не понятно, а уж по английски и подавно, слишком много непонятной математики

Если дочитаете до конца страницы , там имеются ссылки на готовые имплементации

Да я с этой страницы уже всё стянул, там вообще не реально разобраться (по крайней мере на моём уровне), что там, к чему много отдельных модулей, заточенных под другие цели и напичканные всем чем можно.
Мне бы вот найти, по полочкам что бы было, вот функция создания ключей, вот функции шифрования, вот дешифрования и всё большего и не надо.
2cupertino а вы сами использовали этот ECC?

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


кстати болталась гдето в сети pdf русского перевода книжки Шнайдера. Набираете в google Шнайдер криптография вылезает куча ссылок. :-) лучше конечно шифровать симметричным ключом, а сам симметричный одноразовым.

Только он Шнайер. Брюс Шнайер (Schnyer), а не Шнайдер.
В любом случае, от этой книжки до практической реализации как пешком до Луны, хотя без нее тяжко.


Шифровать в лоб RSA не очень хорошо, он очень медленный. Так не делают даже на персоналках, где мощности процессоров несравнимы.
Классический вариант заключается в шифровании основного потока данных быстрым блочным шифром (AES/Blowfish), а вот симметричные ключи к этому шифру закрыты уже RSA или ECC.

Кроме того, есть методы снятия данных без влезания внутрь устройства. Например, анализируя потребление энергии можно сделать выводы о проходящих в данный момент операциях, ну и так далее. Почитайте FIPS-140-2 -- там много на эту тему.

Вообще, много есть разных способов. Я бы предложил топикстартеру немного более конкретизировать задачу. В частности, вопрос - данные приходят к устройству по незащищенному каналу? Где будет производится расшифровка? На том ноутбуке, который используется для считывания?

Задача в сохранение данных в зашифрованном виде, и возможности расшифровать их только на ПК хозяина, хакер может только украсть это устройство, и дальше пытаться с ним возиться, но получить данные с eeprom, и получить ключ для дешифровки в будущем он не должен! вот основная задача.
Кстати ту нашел простой алгорим ECC (http://www.intuit.ru/department/security/networksec/11/2.html) может кто нибудь на примере(на числах) показать, как это работает, а то как то туго у меня идёт!

Вот этот ноутбук, с которым ходят, собирают данные - это уже ПК хозяина?

да, на нём установленна программа, котрая и будет дешифровывать!

Тогда дарю идею:

После того, как из девайса считанны данные, большой брат генерирует случайную (именно случайную) последовательность байт длинной в размер EEPROM и передает ее девайсу, при этом девайс укладывает эту последовательность в EEPROM на место архива. Большой брат, конечно, сохраняет сгенерированную последовательность у себя. Эта последовательность - суть одна страничка одноразового шифроблокнота

Далее, девайс при очередной записи в EEPROM пишет байты как результат операции XOR собственно данных записи и значения, лежащего в той ячейке EEPROM, куда будем писать (т.е. с очередным байтом ключа). После чего указатель записи перемещается на следующую ячейку. Конечно, две записи в одну ячейку производить нельзя (да это и не требуется). Указатель на свободное место в архиве храните в другом месте.

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

да можно, но проблемма в том, что ключи должны быть прочно зашиты в устройство и быть неизменны, так требует заказчик.

От модератора.
Из сообщения удалено излишнее цитирование.