Криптография для эмбеддера. Введение в ассиметричные алгоритмы.



У меня в черновиках «завалялась» небольшая статья по ассиметричной криптографии. Статья коллеги a9d приводит пример использования «модульной арифметики», (правда в другом ключе) но не объясняет «как это работает». Т. к. коллега запретил комментарии к своей статье (ИМХО, зря, в комментариях самое вкусное), я позволю себе опубликовать данную недоработанную статью.


В последнее время в сообществе возрос интерес к вопросам криптографической защиты информации и я решил написать небольшую статью (вернее продолжить предыдущую).



В предыдущей статье мы рассмотрели один из вопросов – шифрование и косвенную аутентификацию на базе симметричного шифрования. Механизм такой аутентификации работает и является достаточно надежным. Но, на практике, в таком виде, он используется редко по одной причине – он не удобен для использования в реальных системах. Данный алгоритм обладает одной неприятной особенностью: он симметричен, то есть отравитель и получатель должны владеть одинаковой копией секретного ключа шифрования.

В лабораторных условиях вроде как все просто, сгенерировали ключ, записали его копию в 2 устройства и все ок. Ключ знаем только мы, и мы не заинтересованы в компрометации ключа. А как быть в реальных условиях, когда устройства стоят на объекте, их обслуживанием занимается некая организация, которой мы потенциально не доверяем. Надежность такой системы стремится к нулю, у нас нет гарантии, что при первичной «заливке» ключей не произойдет компрометации ключа (проще говоря, что ключ не будет кем-то скопирован).

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

Попытаться решить эту проблему исключительно на симметричных алгоритмах можно (но не нужно). Например, «на заводе» прописываются транспортные ключи, на этих ключах шифруется канал, потом одно из устройств генерирует боевой ключ и по зашифрованному каналу передаёт его второму устройству, после чего устройства стирают транспортные ключи и переходят на боевые. Но такая схема имеет кучу уязвимостей. Особенно весело, когда устройств не 2 на есть некая сеть, и структура сети может меняться.

Банальный пример – продвинутая система автосигнализации. Есть центральный замок, есть «брелки» (их много) по команде с которых нужно открывать дверь. Владелец может приобрести новый, дополнительный «брелок» и нужно «добавить» брелок центральный замок («спарить» устройства). При этом, заниматься этой процедурой будет автомеханик, к которому нет доверия ни у производителя, ни у владельца. В данном случае автомеханик – потенциальный злоумышленник (man-in-the-middle). Значит, нам нужен алгоритм, который бы учитывал все эти особенности, позволял избежать перехвата секретного ключа на этапе «первичной инициализации» и не был уязвим к атакам man-in-the-middle.

В конечном итоге мы придём к решению на ЭЦП (электронная цифровая подпись). Но давайте по порядку.

Существуют решения (математические), которые позволяют обменяться секретным ключом (либо совместно выработать секретный ключ) по открытому каналу, не выдав сам ключ. Самые известные – это схемы Диффи — Хеллмана и Эль-Гамаля.

Есть чудесный видеоролик, который на пальцах объясняет работу таких схем (в данном случае это алгоритм Диффи — Хеллмана).



Но, в чистом виде, такая схема уязвима к атаке man-in-the-middle. В данном случае Ева может не просто слушать канал, а стать в разрыв канала. Тогда, произойдет следующее, Алиса выработает общий секретный ключ с Бобом Евой, а Боб выработает свой секретный ключ с Алисой Евой. Алиса и Боб считают, что они общаются напрямую друг с другом, а на самом деле Ева перехватывает трафик, расшифровывает сообщение от Алисы на ключе «Алиса-Ева», просматривает сообщение, и отправляет его Бобу (зашифровав на ключе «Ева-Боб)»

Бороться с такой атакой будем уже в следующей статье (если это кому-то интересно), заодно я попробую продемонстрировать работу ЭЦП на конкретном алгоритме. Извиняюсь за то, что я обрываю рассказ на самом интересном месте, я изначально хотел просто выложить ролик, потом решил добавить немного описания.
  • +4
  • 10 января 2013, 00:22
  • e_mc2

Комментарии (153)

RSS свернуть / развернуть
Как-то слишком кратко и я ожидал немного инфы о RSA, ну и вообще возможность пообсуждать тематику вон той статьи без комментариев)
Алсо, лично я не очень люблю ролики (хотя… как раз сейчас у меня загружен нетбук, так что можно и ролик посмотреть...), неплохо было бы продублировать его текстом.
0
  • avatar
  • Vga
  • 10 января 2013, 01:34
неплохо было бы продублировать его текстом

Продублирую, и приведу пример реализации ЭЦП на основе «модульной арифметики» но уже в следующей статье. Заодно объясню некоторые тонкости (например, почему берется модуль именно по простому числу и т. д.).

Хотя, я смотрю, интерес к теме угасает. Боюсь, если написать статью с кучей непонятных формул – ее вообще мало кто будет читать. Но я попробую :)
0
совсем не угасает, пишите!
0
>приведу пример реализации ЭЦП на основе «модульной арифметики»

CRC-16/CRC-32 и т.п., их схемная и прогрпммная реализация, но зачем? Может быть ограничится ссылками на готовые старинные хорошие статьи на эту тему (для начинающих).

P.S. В связи с обильным окучиванием плодов технологии BitCoin техно-гения Сатоши Накамото (а может это просто аватар команды разработчиков?) в народных массах ВДРУГ проснулся огромный интерес К КРИПТОГРАФИИ. Это как 8-12 лет назад среди авторов комп.журналов и юзеров модно стало «разбиратся» в тонкостях работы 3-х мерных ускорителей для видео-карт на сермяжном уровне.

В данном случае совет: делать статьи такого общего обзорного толка типа дайджестов, т.е. обзоров хороших популярных статей специалистов (для начинающих) и более серьезных работ, для тех кто идет или пойдет дальше в этом направлении. Естественно с указанием ссылок на них, ну и копипаст/отсебятина конечно же приветствуется.
0
CRC-16/CRC-32

Эти алгоритмы – это контрольная сумма, но ни как не ЭЦП. Они могут обеспечить целостность информации, но ни как не аутентичность и неотрекаемость. ЭЦП – это ассиметричный алгоритм, и ничего общего с подсчетом контрольной суммы он не имеет (кроме того, что он тоже может обеспечить целостность).

P.S. А причем здесь BitCoin? Там, насколько мне известно, «добыча» построена на сложности вычисления хеш-функции (хотя я могу ошибаться, я не интересовался данной «валютой»). Мне кажется, Вы путаете разные криптоалгоритмы, и их назначение.
0
CRC уже не хеш ;)
-1
CRC уже не хеш ;)

Почему не хеш? CRC можно рассматривать как частный случай хеш-функции. Понятно, что криптостойкость у CRC-16 мизерная, но формально – это необратимое преобразование (свертка) над открытым текстом с результатом фиксированной длинны.

Хеширование (иногда «хэширование», англ. hashing) — преобразование по детерминированному алгоритму входного массива данных произвольной длины в выходную битовую строку фиксированной длины
0
Если это хеш, то почему это ее нельзя использовать как подпись? В качестве подписи можно использовать, что угодно. Даже тупую сумму. Все зависит от важности.
0
Нельзя. Если Вы можете проверить хеш – значит Вы знаете алгоритм и все его параметры (соль, и т д.). Проверка хеш – это повтор действий при расчете хеша.

Что Вам мешает Вам написать новый документ (например, дарственную на свое имя) и пересчитать по нему хеш (для его расчёта вы знаете все параметры, алгоритм симметричен, хоть и необратим).

Потом, вы предъявите такой документ в юридической инстанции, и говорите, вот мол, у меня есть дарственная на имущество, в виде электронного документа.
А потом выйдет зашита, и докажет, что СRC, или хеш можно подделать, т. к. алгоритм симметричен. И как минимум, «проверяемый» и «проверяющий» знают общий секрет (соль, общий ключ, если таковые предусмотрены алгоритмом). Что, в таком случае «проверяющему» запрещает подделать подпись (на самом деле хеш) «проверяемого»? Ничего, у него для этого есть все возможности. Таким макаром, «проверяемый» может отказаться от ответственности. Это и есть «отрекаемость».

А вот «неотреакаесость» – самый важный момент ЭЦП.
+2
Как я понимаю часто использовал цифровые подписи?
С такой логикой, что мешает пересчитать SHA-2? Ведь все константы известны.
-1
Возможно, Вас сбивает с толку тот факт, что ЭЦП обычно считается не по самому документу, а по хеш-у от документа (например, сертификаты x509). Но это сделано сознательно, для ускорения вычисления ЭЦП, хотя, в общем, это ослабляет защиту всей иерархии (PKI).

Пересчитать SHA-2 я смогу. Но я не смогу просчитать подпись, наложенную на SHA-2. Хеш можно пересчитать, получим новое значение хеш, но вот пересчитать ЭЦП для нового значение хеш (не зная секретного ключа ЭЦП) считается невозможным.

Хотя, теоретически возможна атака на хеш. Тобиш модифицировать документ таким образом, чтобы документ изменился, а значение хеш-функции не изменилось (например, радужные таблицы для MD5).
+2
Вот интересно. Используем хеш SHA-2 и бац и не можем подделать цифровую подпись, потому что не знаем секретный ключ. Меняем SHA-2 на CRC и вдруг мы узнаем секретный ключ, и можем подделать подпись. Парадокс…
-3
Подпись мы подделать не можем. А вот добиться коллизии хеш-функуии можем. Например, выход CRC-16 имеет всего 56536 вариантов (извиняюсь за кепство). Соответственно, можно попытаться изменить текст таким образом, что бы CRC-16 получилась такой, как в оригинале. Тогда подпись (наложенную на CRC-16) перечитывать не придётся. Но, на практике, никто по алгоритму CRC-16 хеш не считает, и вероятность коллизии приравняют к нулю. К прмеру, ГОСТ-овский хеш имеет длину 32 байта.

Или Вас смущает, что ЭЦП нельзя пересчитать? Дык это асимметричный алгоритм, не зная секретного ключа подпись вычислить нельзя (зато можно проверить, зная открытый ключ).
+2
Нет. Меня смущает
Эти алгоритмы – это контрольная сумма, но ни как не ЭЦП. Они могут обеспечить целостность информации, но ни как не аутентичность и неотрекаемость.

а теперь оказывается их можно использовать. В качестве подписи можно использовать любую хеш функцию. Это лишь дело надежности а не паранойи.
-2
Да, нет. Хеш используется для «сертки». Корме целостности, хеш никакой защиты не обеспечивает. А вот по значению хеш –функции считается ЭЦП, именно ЭЦП обеспечивает аутентичность и неотрекаемость.

Теоретически, ЭЦП можно считать по саму документу (разбив его на фрагменты) но это очень долго. Советую ознакомиться с базовыми принципами ЭЦП.
+2
Ты уже определись как-то. Такое ощущение, что ты начитался теории и никогда этим не занимался и не использовал.

Глубоко насрать какая хеш функция используется. Имеет значение только важность данных.
-2
Ты уже определись как-то.

С чем? Я вроде как свои позиции не менял.

В качестве подписи можно использовать любую хеш функцию
Глубоко насрать какая хеш функция используется.

Вы бы все-же прочитали ту статью в википедии о ЭЦП. Понимаете, ЭЦП обеспечивает 3 вещи: целостность информации, однозначную идентификацию автора и невозможность отказа от авторства. Именно эти 3 вещи делают ЭЦП полным аналогом рукописной подписи (и во многих странах ЭЦП и обычная подпись человека имеют равную юридическую силу). Эти 3 вещи обеспечиваются самим алгоритмом ЭЦП, алгоритмы хеша таким комплексом свойств не обладают. Но есть момент — алгоритмы ЭЦП работают, как правило, с данными фиксированного размера, и сам алгоритм достаточно медленный. По этому на практике подпись обычно считают от хеш функции а не от самих данных. Например алгоритм ГОСТ Р 34.10-2001 принимает на входе значение хеш по ГОСТ Р 34.11-94, но на самом деле на вход можно подать абсолютно произвольный блок данных длинной 256 бит.

Но тот факт что ЭЦП часто считают по значению хеш функции от текста абсолютно не говорит о том, что хеш это и есть подпись. Это разные алгоритмы. Если бы хеш мог выполнять функции ЭЦП, поверьте, никто бы тогда не выдумывал ассиметричные алгоритмы для ЭЦП, не городили бы целую инфраструктуру с сертификатам и центрами сертификации ключей.

Вот, предположим, что у вас есть сообщение и его хеш (например, как частный случай, CRC-16, не принципиально). Ну проверили мы CRC-16 по тексту, ну предположим оно сошлось. Что делать дальше, как однозначно идентифицировать автора? Как доказать авторство, если автор вдруг заявит «а я ничего не подписывал»?
+1
Не обращайте внимания на троля.
+2
Вот, предположим, что у вас есть сообщение и его хеш (например, как частный случай, CRC-16, не принципиально). Ну проверили мы CRC-16 по тексту, ну предположим оно сошлось. Что делать дальше, как однозначно идентифицировать автора? Как доказать авторство, если автор вдруг заявит «а я ничего не подписывал»?

Секретный ключ снова стал общедоступным?
0
Секретный ключ снова стал общедоступным?

Поясните, плиз, какой именно секретный ключ Вы подразумеваете, какой алгоритм Вы хотите использовать? (просто пока у нас есть только CRC-16).

Вы же говорите

В качестве подписи можно использовать любую хеш функцию

Откуда появился секретный ключ?
0
Поясните, плиз, какой именно секретный ключ Вы подразумеваете, какой алгоритм Вы хотите использовать? (просто пока у нас есть только CRC-16).

Ты используешь подписи без шифрования? Ты, что их в открытом виде передаешь?
Откуда появился секретный ключ?

Потому-что это цифровая подпись. Или ты знаешь виды подписей без шифрования? Поделись, мне такие алгоритмы неизвестны.
-1
Ты используешь подписи без шифрования? Ты, что их в открытом виде передаешь?

Да, ели не требуется защита от НСД. Шифрование и ЭЦП – это разные алгоритмы. Шифрование обеспечивает защиту от несанкционированного доступа, ЭЦП – целостность и т. д. Иногда нужно обеспечить и то и другое, иногда что-то одно.

Например, я хочу разослать всем сотрудникам письмо «завтра мы не работаем». Чтобы это не выглядело шуткой, я могу наложить свою подпись на это сообщение, тогда сотрудники смогут убедится в его аутентичности. А вот шифровать сообщение смысла нет, оно не секретно. Или другой пример – я могу подписать ЭЦП публичный договор присоединения и выложить его на сайте вместе с подписью. При определенных условиях, такая подпись будет иметь юридическую силу. Но шифровать договор смысла нет, он публичный. Если я его зашифрую – как пользователь сможет ознакомиться с его содержимым, общих ключей шифрования у нас нет. Или сертификаты ЭЦП, списки отозванных сертификатов, они должны быть публичны, но подписаны центром сертификации.

Или ты знаешь виды подписей без шифрования?

Конечно знаю. Все используемые современные алгоритмы ЭЦП рассчитывают/проверяют подпись, при этом сами данные не модифицируются. Как я уже писал, обычно подпись вообще накладывается на результат хешфункции, сами данные (текст) алгоритм ЭЦП в этом случае не получает вообще, только хеш. Вам наверное будет тяжело в это поверить :) А алгоритм ЭЦП похож на направленно шифрование, но данные при этом не скрываются, просто вычисляется некоторый массив байт, который и является подписью. Этот массив байт прикладывается к исходному документу, получается «электронный документ». Если не верите, зайдите на любой центр сертификации ключей (пример на этот), скачайте какой нить сертификат (*.cer). И откройте виндовым вьювером. Там открытая информация о издателе, владельце. Но сам сертификат подписан ключом издателя.
+1
Понятно. Ты никогда не использовал подписи и не делал их. А тупо начитался вики.

Есть четыре байта информации, передаются в открытую. Нужно сделать подпись длинной в один байт. Как такое реализуется? Говорю сразу эта задача легко решается и легко взламывается. Но сейчас речь не о взломе.
-3
*уточнение, алгоритм хеш функции известен всем. Разумеется и взломщик его знает.
0
Понятно. Ты никогда не использовал подписи и не делал их. А тупо начитался вики.

Ок, давайте на этом и остановимся. Но я все жe порекомендовал бы Вам ознакомиться с той самой вики. Откройте Ваш любимый алгоритм RSA, полистайте до раздела цифровая подпись и посмотрите алгоритм реализации. Особое внимание обратите на фразу:

Заметим, что подписанное сообщение m не зашифровано. Оно пересылается в исходном виде и его содержимое не защищено от нарушения конфиденциальности. Путём совместного применения представленных выше схем шифрования и цифровой подписи в системе RSA можно создавать сообщения, которые будут и зашифрованы, и содержать цифровую подпись.
0
Ну вот и ты продемонстрировал свои знания уровнем вики.

А задача простейшая и решается за секунды.

Берем CRC8 и нестандартный полином. Полином в этом случае будет выступать ключом шифрования. Делаем хеш. Задача решена. Теперь только стороны знающие секретный полином могут проверять и делать подписи. Либо вносится арбитр который будет подтверждать подлинность подписи.
Также можно использовать секретную соль. И будет тоже самое.

Либо вообще сгенерить RSA-8 и шифровать им хеш CRC-8
-3
Эти алгоритмы – это контрольная сумма, но ни как не ЭЦП. Они могут обеспечить целостность информации, но ни как не аутентичность и неотрекаемость. ЭЦП – это ассиметричный алгоритм, и ничего общего с подсчетом контрольной суммы он не имеет (кроме того, что он тоже может обеспечить целостность).

И как видишь все условия будут соблюдаться. Правда ты добавил отсебятины «ассиметричный алгоритм», в определении этого нет. Там лишь сказано, что используют хеш из которого чрезвычайно сложно восстановить сообщение.
-1
И вот твоя любимая вики

Поскольку подписываемые документы — переменного (и как правило достаточно большого) объёма, в схемах ЭП зачастую подпись ставится не на сам документ, а на его хеш. Для вычисления хэша используются криптографические хеш-функции, что гарантирует выявление изменений документа при проверке подписи. Хеш-функции не являются частью алгоритма ЭП, поэтому в схеме может быть использована любая надёжная хеш-функция.

Хеш функция не имеет значения. Можно использовать любую. Имеет значение только важность информации.
-1
Поздравляю, Вы изобрели собственный алгоритм ЭЦП. Только он не работает, не обеспечивает ни идентификации отравителя ни неотрекаемости. Проблема в том, что все участники владеют одним и тем-же секретом (полиномом).

Предположим, у нас есть 2 участника и арбитр. Арбитр получает подписанное сообщение, проверяет секретную контрольную сумму на секретном полиноме. Сумма сходится, все ок. Вот только кто автор сообщения? Это может быть любой из двух участников, так как они оба знают одинаковый секрет. Идентифицировать отправителя мы не можем.

Аналогично с неотрекаемостью — каждый из участников может заявить: «это не я подписывал документ, это тот, другой, у него точно такой-же секрет как и у меня».
+1
Vga внес уточнение. Такие подписи использовались раньше.

Вот только кто автор сообщения?
Авторство определяется по полиному.

Это может быть любой из двух участников
Нет. Полином только один и его знает только отправитель и арбитр.
0
Понимаете, идея ЭЦП в том, что только я (и никто другой, даже в теории) могу наложить свою ЭЦП. Только я владею тем самым секретным (иногда, в контексте ЭЦП, его называют «персональным») ключом. И никто кроме меня. Даже центр сертификации, который издает мой сертификат открытого ключа, не имеет доступа к моему секретному ключу.

Ну исключили Вы из троих «подозреваемых» одного, осталось двое – я и арбитр. Мне показывают подписанный платежный документ, а я говорю – я его не подписывал, наверное, это злой «арбитр», у него храниться копия моего секретного полинома. Доказать, что не произошла компрометация копии секретного полинома со стороны «арбитра» невозможно. И соответственно, ни о какой надежности речь идти не может.
0
Понимаете, идея ЭЦП в том, что только я (и никто другой, даже в теории) могу наложить свою ЭЦП. Только я владею тем самым секретным (иногда, в контексте ЭЦП, его называют «персональным») ключом.

Арбитр не только проверяет. Он не может генерировать сообщения. Именно так раньше работали системы.

Ну исключили Вы из троих «подозреваемых» одного, осталось двое – я и арбитр.

Связь с арбитром всегда происходит по защищенному каналу. Само же подписанное сообщение может передаваться как угодно. Ключ арбитр получает тоже по защищенному каналу.

Доказать, что не произошла компрометация копии секретного полинома со стороны «арбитра» невозможно.
Это возможно только в случае подмены арбитра.

И соответственно, ни о какой надежности речь идти не может.
Какая надежность???? Так раньше работали.

Ей богу реализуй хотбы одну цифровую подпись. А потом уже пиши какие угодно статьи. Ты начитался тупо теории.
0
*Арбитр только проверяет
0
Не важно насколько круто защищён арбитр. У него хранится копия моего секретного ключа. Даже минимальная, и очень высосанная из пальца угроза – это уже повод для того, чтобы я мог отказаться от авторства. Доказать, что ключ не был скомпрометирован на стороне арбитра невозможно.

Я вот честно, не понимаю зачем вы пытаетесь изобрести свой алгоритм. Возьмите и реализуйте стандартный, там все эти моменты давно улажены.
+2
Это и есть стандартный алгоритм подписи.
0
Вы серьезно считаете что совершенно неподготовленному человеку стоит браться за реализацию какого-нить стандарта ЭЦП? DSA — разрядности чисел помутнят сознание, а ECDSA — элл. кривые вообще взорвут неокрепший мозг)
+2
Ей богу реализуй хотбы одну цифровую подпись. А потом уже пиши какие угодно статьи. Ты начитался тупо теории.
Тупо реализовать неизвестно что, не зная теории — тоже сомнительное достижение.
+2
Конечно. Сначала теория, потом реализация а после уже статьи. Без реализации и проверки на практике это уже отсебятинна основанная на личных убеждениях.
0
Не знаю как уж ты это применяешь на практике, но твоя информация больше похожа на отсебятину на личных заблуждениях. И не только в данном случае.
+1
Зночит в материалах про подписи врут и порят чушь. Там ведь советуют использовать хеш функцию, без уточнения какую именно. А говорится только о надежности. Использовать соль для удаления статики, чтоб нельзя было спамить отловленными пакетами. Использовать ассиметричный алгоритм без уточнения длинны ключа а лишь сказано о надежности. Одним словом п**дять и обманывают.

Я тебе скажу сразу. Я проверял на коротких сообщениях. Коллизии не нашел, подходящих под мой размер и формат. Попадались лишь только мусорные которые будут игнориться. И это важный плюс CRC16. Можно быстро проверить все возможные коллизии. В придачу с акселератором можно быстро генерить подписи.
-1
Авторство определяется по полиному.
«Это не я подписал, это арбитр!». Алсо, когда арбитр знает секретный ключ подписи — есть риск его утечки. Именно поэтому Sony и Nintendo используют асимметричные схемы — чтобы ключи подписывания игр нельзя было извлечь из прошивок консолей. Впрочем, у нинтендо ключи таки угнали, а у сони нашли другую дырку — возможность подсунуть свой код в подписанный исполнимый файл.
Аналогичный фокус, чтобы отсечь возможность написания кейгенов, применяет HITECH (делают компиляторы для PIC). Правда, и он обходится — универсальный кейген для них подменяет публичный ключ в ехе.
+1
Алсо, когда арбитр знает секретный ключ подписи — есть риск его утечки.
А еще есть риск подмены арбитра или атаки на канал связи с ним. Например, есть программы, проверяющие свою лицензионность через арбитра (сервер в интернете, сервер лицензий). Помогает им это довольно слабо — как правило арбитра подменяют.
0
Vga внес уточнение. Такие подписи использовались раньше.
Алсо, MAC — не подпись. Это всего лишь средство контроля правильности сообщения, когда источнику и получателю известен некий общий секрет.
+2
С арбитром это уже не MAC. Получатель не владеет ключом.
0
Берем CRC8 и нестандартный полином. Полином в этом случае будет выступать ключом шифрования. Делаем хеш.
Насколько я вижу, это имитовставка, а не ЭЦП.
0
Оставляем только арбитра.

Также с RSA8 погорячился. Не выйдет подпись в один байт.
0
Теперь только стороны знающие секретный полином могут проверять и делать подписи.
ЭЦП можно проверить не зная секретного ключа, вашу пародию нет.

Либо вносится арбитр который будет подтверждать подлинность подписи.
Ну это древний способ сэкономить количество ключей симметричной криптосистемы, довольно таки УГ, ибо требует постоянного коннекта с арбитром. ЭЦП при развертке иерархии PKI может работать в оффлайне, ибо валидность публичного ключа приложенного к документу может подтвердить CA своей подписью.
+2
ЭЦП при развертке иерархии PKI может работать в оффлайне, ибо валидность публичного ключа приложенного к документу может подтвердить CA своей подписью.

Это современный алгоритмы. И даже сейчас глубоко побую какая хеш функция используется. Один хер ключ остается секретным. Коллизии далеко не всегда являются сметрельными.
0
И даже сейчас глубоко побую какая хеш функция используется

Если Вы используете ЭЦП для побаловаться – пофиг на все. Можете CRC-16 назвать цифровой подписью, ели Вам так нравиться.

Но ели вам нужна надежность, то далеко не все пофиг. Например, ели вы хотите, чтобы ваша подпись имела юридическую силу – вы должны использовать определенные алгоритмы, с определенными параметрами, использовать сертифицированный софт и пользоваться услугами аккредитованного ЦСК.
+1
Если Вы используете ЭЦП для побаловаться – пофиг на все. Можете CRC-16 назвать цифровой подписью, ели Вам так нравиться.

ОК. Теперь всякое хлам буду подписывать только SHA-2. Побую на CRC акселераторы встроенные во многие микроконтроллеры. Побую, что даже с CRC чрезвычайно сложно сделать пригодный фек на основе коллизии. Ведь главное надежность. А ценность данных неимеет значение. Везде буду тулить ARM.

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

Та я каждый день между микроконтроллерами только и обмениваюсь информацией о счетах, доверенностями на квартиры. И обязательно каждый алгоритм сертифицирую.
0
Побую, что даже с CRC чрезвычайно сложно сделать пригодный фек на основе коллизии.
Как раз CRC очень легко подгоняется под любое желаемое значение.
+2
Как ты сообщение будешь под CRC подгонять? Это очень сложно сделать. И главное, чтоб оно имело хоть какой-то смысл. До сих пор используют MD5 суммы, потомучто очень сложно добавить троян не меняя хеш.
-1
Зависит от сообщения. Как правило приходится подгонять CRC за счет некритичных частей сообщения (с точки зрения взломщика некритичных — лишь бы схавало нужный ему параметр). В случае же, когда в сообщение можно безболезненно добавить левые данные — вообще лафа, для CRC32 достаточно модификации 4 байт для подгонки хэша под любое желаемое значение. Например, если имеем пакет вида [Type][Size][Data] и не проверяем соответствие размера пакета его типу — достаточно увеличить поле данных и дописать мусор в конец сообщения, принимающая сторона мусор проигнорирует, а CRC будет правильным.

MD5 — другое дело, подогнать под него сообщение (т.е. создать коллизию) — на много порядков сложнее, чем для CRC.
0
a9d. вот давайте я попробую вам кое-что пояснить.
пусть есть сообщение, данные, и назовем их М. и вы хотите передать это сообщение М, да так чтобы никто по пути его не сможет изменить незамечено. Если вы сделаете просто некий отпечаток сообщения М (результат хэш-функции или то что вы писали), который мы обозачим S, то передавая по каналу связи сообщение M и его отпечаток S, то любой может модифицировать ваше сообщение M, заново вычислить S и отправить дальше. Если же вы полагаетесь на неизвестность альгоритма генерации отпечатка — это не есть гуд, ибо как я понимаю, написать подобный алгоритм вы хотите сами, но проверить свою функцию не сможете в силу незнания даже банальных способов и методик вскрытия. Если использовать известную криптографически стойкую хэш-функцию, то только с солью, которая должна быть известна обоим участникам обмена сообщением M. причем битовая длина соли должна быть ощутимо трудной для полного перебора. В таком отпечатке есть существенный минус. все кому я отправляю сообщение знают эту соль и могут генерировать любые S от моего имени. Это тоже не есть гуд в ответственных задачах. в быту если у вас есть только 2 устрйоства и больше никого, можете использовать такую псевдо-подпись. но вопрос зачем?
+1
не дописал. для вышеприведенного примера логичней шифровать канал симметричным криптоалгоритмом. В случае если нужна подпись которую могут проверить и другие участники обмена, не имея ключа для генерации подписи, то надо перехоить уже к взрослым вариантам, как например DSA
0
Я говорил о использовании хеша в подписи а не использования хеша вместо подписи. Улавливаешь разницу?? Как ты собрался менять хеш в подписи не зная открытого ключа?

Конечно появляется вероятность коллизии. Но обычная временная метка(в качестве соли) сведет эти коллизии почти на нет.
0
цитирую
Берем CRC8 и нестандартный полином. Полином в этом случае будет выступать ключом шифрования. Делаем хеш. Задача решена. Теперь только стороны знающие секретный полином могут проверять и делать подписи. Либо вносится арбитр который будет подтверждать подлинность подписи.
Также можно использовать секретную соль. И будет тоже самое.
0
где в вышеприведенной цитате криптосистема с открытым ключом?
0
в вырванной фразе нигде. Разговор идет о хеш функции в подписи а не хеш функция вместо подписи.
0
Ты вырвал фразу из контекста. Это простейший пример ЦП который раньше использовался вместе с арбитром.
0
Это a9d. Он говорит А, а подразумевает Б. Был пример:
Я: Высокоприоритетная задача съедает 100% времени процессора и никогда не заканчивается. Получит управление низкоприоритетная?
Он: Да
Я: Как?!
Он: Конечно получит, как только ты уберешь незаканчивающуюся высокоприоритетную задачу.
+1
42
-2
Если ты имел в виду «вызывающе неверная информация», то это 4.2.
Диалог несколько утрирован и сокращен, но суть его именно такая. Когда найду, в каком топике это было — дам пруфлинк.
0
Это a9d. Он говорит А, а подразумевает Б.
Или, точнее, «говорит А и подразумевает Б». При этом подразумеваемое далеко не очевидно и меняет смысл сказанного на близкий к противоположному.
0
Я говорил о использовании хеша в подписи а не использования хеша вместо подписи.

Но ведь Вы говорили:

В качестве подписи можно использовать любую хеш
функцию

Или я неправильно Вас понял?

Но обычная временная метка(в качестве соли) сведет эти коллизии почти на нет.

Коллизии неизбежны при применении хеш. Как я уже кепствовал, CRC-16 на выходе имеет 65536 различных значений. Как бы вы не солили, какой бы полином не использовали – данный алгоритм будет иметь 65536 значений на выходе. Хотите уменьшите вероятность коллизии – используйте хешфункции большей размерности.
0
Можно любую хеш использовать. Главное, чтоб она удовлетворяла заданной надежности. Если разговор идет о подписи, то самособой разумеется, что она сумма зашифрована.

65536 значений тебе мало??? да в управляющем пакете максимум 1000 комбинаций набегает. Вероятность коллизии минимальна и ее легко проверить.
0
читать и ещё ращ чиатть матчасть. не все полиномы одинаково полезны, а для построения GF(256) — чертовски мало. Но, a9d, не обижайся, но ты сам не ведаешь чего пишешь и говоришь)
+2
Ну ведующий. Расскажи как использовать подписи на микроконтроллерах. Как ты туда затолкаешь надежный хеш и т.п. Очень интересно послушать куда и как это будет влазить.
-1
моё видение — эллиптические кривые спасут отца русской демократии. разрядности вполне усваиваемы микроконтроллерами, даже AVR. на данный момент моя дипломная работа как раз связана с подписями на элл.кривых и конкретно их реализацией на AVR (читсо спортивный интерес). надежный хэш? — возьму наш гост или SHA-3. это осуществимо
+1
И как это будет работать на практике? Микроконтроллер все время будет занят расшифровкой а не работой.

Хлев можно оставить открытым. Но корова тогда убежит и волк придет и захорчит ее. А можно поставить амбарный замок и не трахать мозг. Но я вижу ты хочешь поставить замок с проверкой сетчатки глаза.
От кого и что ты собрался защищать? Почему AVR занимается шифровкой важных данных? и т.п. Это вопрос здравого смысла.
0
ну коли уж о коровах… если мне надо будет защитить корову, защитить её от переклеймения и подмены другой коровой, то я воспользуюсь цифровой подписью малой разрядности. если мне надо будет защитить майбах то использую цифровой подписью бОльшей разрядности.
А если серьезно, я всегда смотрю задачу. если передача в открытую представляет угрозу для передаваемой информации, то применю шифрование. Какое? зависит от важности информации. Наивно думать что вся криптография это некий дикий и жутко неповоротливый монстр. А ведь стоит всего лишь зашифровать поток данных потоковым шифром VMPC, чтобы получить достаточно безопасный канал. хотите больше безопсности? пожалуйста: ГОСТ, AES, etc. Устройств больше двух и необходим пиринг? Протокол Диффи-Хеллмана. Ну если уж совсем что-то важное передаете, то и сертификатами можно не брезговать, причем доверенной стороной может быть и производитель железа. Хотите больше безопасности: используйте больше плюшек, больше разрядность. меньше — меньше плюшек, меньше разрядность. Главное четко представлять для чего что нужно. Перечитайте комментарии коллеги e_mc2 в части свойств ЭЦП. Криптография очень интересная и увлекательная наука, но к счастью ( а может и к чьему-то сожалению) это наука. Со своим фундаментом, нормами, принципами, теоретической и парктической частями.

P.S.: обмен ключами ECDH займет по прикидкам максимум 1 секунду. шифрование данных с помощью RC4 ~20 тактов на байт. это много?
+1
Откуда в микроконтроллерах уже появились большие пакеты?? Зачем большие пакеты ты хешируешь неподходящей функцией?

Ну а делше ты перевел тему в другое русло. Зачем использовать SHA там где можно и обойтись CRC?
-1
где в моем комментарии шла речь о больших пакетах? для RC4, длина блока 1 байт. для госта размер блока 64бита = 8 байт. где много? Что знаит неподходящей функцией?
если уж залезли в область крипографии, даже из уважения к себе почитайте как обстоят дела в этой науке, просто для того чтобы иметь представление что с чем едят. Просто складывается ощущение что пару умных слов услышали, вам открылась в них истина и вы рьяно доказываете в чем, мягко гворя, плаваете как пробка.
И я не устану повторять, в реальных ЭЦП (для которых должны выполняться контроль целостности, защиту от подделки, и доказательство авторства), необходимо использовать только и только криптокграфически стойкие хэш-функции. Никакая CRC и подобные таковыми не являются, в силу того что они предназначались совсем для других задач.
+2
Пилить RC4 чтоб защититься там где и CRC16 не дает коллизии?
8байт+соль + шифрование и выйдет уже все 16ть.
0
Расскажи как использовать подписи на микроконтроллерах.

А что Вас так смущает в применении ЭЦП на МК? Все зависит от задачи, ели вам нужна серьезная защита – будьте готовы к тому, что ее реализация требует много ресурсов.

Вы наверно мне не поверите (т. к. считаете меня исключительно теоретиком) но в серьёзных системах защиты информации часто применяют отдельные устройства для выполнения криптографических преобразований. Обычно, это устройство на МК, которое подключается к «большому брату», ПК.

Вам может показаться странным, что имя «мощный» ПК мы используем для криптографических преобразований «слабый» девайс на МК, но такой подход имеет огромные плюсы.

В большинстве МК имеются «биты зашиты», установка которых препятствуют внешнему чтению/модификации FLASH/EEPROM после прошивки МК. Это позволяет создать контролируемую среду исполнения программы и обеспечить концепцию «ключ не покидает устройство». В свою очередь, это делает невозможным копирование секретного ключа (ключей). Ключ можно украсть только с устройством, но пользователь это заметит. Незаметно скопировать ключи не получится.
+2
А что Вас так смущает в применении ЭЦП на МК? Все зависит от задачи, ели вам нужна серьезная защита – будьте готовы к тому, что ее реализация требует много ресурсов.

При защите важной информации всегда используют AVR.

Вы наверно мне не поверите (т. к. считаете меня исключительно теоретиком) но в серьёзных системах защиты информации часто применяют отдельные устройства для выполнения криптографических преобразований.
Спасибо кеп. Используют криптопроцесоры либо микроконтроллер с акселератором SHA/RSA.

В большинстве МК имеются «биты зашиты», установка которых препятствуют внешнему чтению/модификации FLASH/EEPROM после прошивки МК. Это позволяет создать контролируемую среду исполнения программы и обеспечить концепцию «ключ не покидает устройство».
Спасибо. Теперь знаю зачем лочат микроконтроллеры.

Я так понял ты намеренно игноришь все что я говорю о важности защищаеммых данных а после самже это и говоришь.
0
совсем не обязательно что ипользуют криптопроцессоры или микроконтроллеры общего назначения с криптопроцессором. Минус таких контроллеров в цене и доставаемости (по крайней мере у меня такой опыт и не единичный). Микроконтроллеры же общего назначеня легко доставаемы, дешевы, довольно быстры. Соверменные криптоалгоритмы имеют требование по простой и легкой реализации как программной так и в железе. Современные, и не очень, алгоритмы обсосаны со всех сторон и найдено столько способов оптимизации программной реализации, что разработчику гораздо проще и деешелве взять обычный МК и в нем реализовать все программно. этого хватает в 90% случаев. в остальных случаях (большие потоки, большие скорости) делают или ПЛИС или в случае военных могут взять отечественный криптопроцессор (в котором спешу заметить, нет ассиметричного шифрования никакого, т.е. опять же надо реализоваывать программно, но это имеет вполне разумное объяснение).
Если связываетесь с реализацией критпографии, настоятельно рекомендую прочитать курс алгебры, прикладную криптографию Брюса Шнайера и введению в соверменную криптографию Нестеренко. Этого хватит чтобы врубится в курс дела.
+1
Микроконтроллеры же общего назначеня легко доставаемы, дешевы, довольно быстры.
Даже PC херово работает с ассиметричными ключами. Сначала посмотри на колличество итераций а после уже делай такие заявы.

Современные, и не очень, алгоритмы обсосаны со всех сторон и найдено столько способов оптимизации программной реализации, что разработчику гораздо проще и деешелве взять обычный МК и в нем реализовать все программно.
0
Коллега rumkin прав, в наших реалиях часто используют МК общего назначения. Вот Вы много знаете микропроцессоров с аппаратной поддержкой алгоритмов ГОСТ Р 34.10-2001 или ДСТУ 4145? Аппаратная поддержка RSA есть у многих, но у нас подпись по алгоритму RSA не будет иметь юридической силы.
+2
но у нас подпись по алгоритму RSA не будет иметь юридической силы.
плюс купить их будет тот еще квест.
+1
Ну, сэмпл МК с криптомодулем (самый жирный из EM Gecko) я выпросил без особых проблем. Хотя пришлось заполнять их бумажку.
0
ну, семпл да, без проблем. а заложить в девайс — совсем другое дело.
+1
Увы. Видимо, тогда остается только брать отечественную ПЛИС и пилить на ней криптоускоритель самому?
0
ну разве что. или отдельный проц, который только тем и будет заниматься на крайний случай.
0
или отдельный проц, который только тем и будет заниматься на крайний случай.

Так часто так и делают. И дело даже не в том, что реализация криптоалгоритма отнимает много ресурсов МК. Ели вам нужны плюшки типа «юридическая сила ЭЦП», то реализация вашего устройства (программный код + схема, ели говорим о МК общего назначения) должен пройти экспертизу.

После экспертизы, ничего в коде (по понятным причинам) уже менять нельзя. Ели у вас прошивка реализует и «бизнес логику» и криптографию, что даже «бизнес логику» Вы поменять (например, пофиксить баг) уже не можете, любое изменение прошивки потребует повторной экспертизы (а это деньги и время).

Часто выгодно сделать «криптомодуль» в виде небольшой отдельной платки, которая занимается только криптопреобразованиями и имеет, например, SPI интерфейс для обмена данными. И провести экспертизу этого устройства как отдельного средства КЗИ.

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

Но, на самом деле, там тоже есть нюансы, и такой подход не всегда может проканать.
0
Хорошее законодательство у Вас. У нас требуют сертифицировать целиком всё СКЗИ даже если использловать сертифицированный криптомодуль.
0
требуют сертифицировать целиком всё СКЗИ

Возможно, я непонятно высказался. СКЗИ требует сертификации, но ведь не весь программно-аппаратный комплекс является средством КЗИ.

Вот, например, я использую СКЗИ RuToken для реализации ЭЦП в своей системе «клиент-банк». Но сертификации подлежит только средство СКЗИ RuToken а не комплекс «ПК + операционная система + клиент-банк + средство КЗИ». Если бы сертификации подлежал весь программно-аппаратный комплекс, то пришлось бы проводить экспертизу каждого конкретного ПК, каждой версии ОС (с конкретным набором обновлений и сервиспаков), и т. д. Но ведь это не реально.

Так и в моем примере – есть криптомодуль (СКЗИ), и есть некое устройство (программно-аппаратный комплекс) который использует данное средство КЗИ.

Или я не прав, в контексте законодательства РФ?
0
правы. недопонял ваш коммент. мне сначала представилась следующая ситуация: есть у нас сертифицированный криптомодуль. и если на его базе мы построим МСЭ, то нам придется всё равно сертифицировать МСЭ.
0
а зачем отечественную? вы гворите про военные применения? в россии есть криптопроцессор к5004ве1 сертифицированный ФСБ. сам я с ним не работал, я вряд ли когда-т буду работать. наверняка для военных есть и други микрухи прост секретные) а отечетсвенные плис кто выпускает? достать сложно/дорого?
0
а зачем отечественную?
Ну, мало ли) Может и там потребуют не реализовывать на ней криптосистему)
сам я с ним не работал, я вряд ли когда-т буду работать.
Сильно секретный или просто незачем?
0
плюс скорее всего ценник такой, что страшно себе представить.
+1
доков в свободном доступе нет. только неполная распиновк и предназначение можно найти. несекртеный, ибо в кассовых аппаратах применяется, но и раскрывать инфу про него, я так понял, никто не собирается
0
емнип, миландр
0
что значит херово?
0
Даже у PC ассиметричное шифрование занимает много процессорного время.

На микроконтроллере подавно. Это легко проверить определив количество итераций.
0
Вашу бы прыть направить в парвильное русло, получилось б че-т дельное и полезное обществу
+1
Пиздеть не мешки ворочить. Ты много сделал? Давай похвастайся.

Я уже допилил для арм каскад Витерби-РС. Потом когда будет не лень покажу. В интернете для микроконтроллеров хуй найдешь его или только либы за деньги.
-1
Ты много сделал? Давай похвастайся.

Я смотрю Вы уже перешли на аргументы уровня «сперва добейся» :)
Коллеге rumkin не нужно ничего никому доказывать, его уровень знаний в данной области виден и так.
+2
К сожалению я не могу похвастаться (некоторые юридические формальности). Витерби-РС — я так понимаю это сверточные кода рида-соломона в связке с алгоритмом витерби?

Так вы шифрование делаете или помехоуйстоячивость?
0
Да инженер-то он похоже годный, вот только общаться в интернетах с ним тяжело. Ну и статьи писать не ахти как умеет. Не блоггер, короче.
0
rumkin Зарегистрирован: 08 марта 2011, 00:29

rumkin 25.01,2013 «Вашу бы прыть направить в парвильное русло, получилось б че-т дельное и полезное обществу»

За два года достижения «Интересны ли сообществу статьи по булевой алгебре и её примении в проектировании цифровых логических схем?»

Отмазка «некоторые юридические формальности».

Прежде чем делать такие выводы, посмотри в свой огород.
0
Что, a9d, обидели тебя, да? Бедолага.
Ну ниче, ты же дал крутой ответ! Достойный настоящего… ребёнка.
-1
И этот человек обвиняет меня в троллинге…
0
я вас обвиняю? обращение шло к a9d. вполне возможно я ошибся веткой
0
Нет. Это в адрес Angel5a подколка. Алсо, под мессагой есть стрелочка. Если ее ткнуть — покажет, на что я отвечал.
0
спасибо за совет)
0
да, я не активный писатель. времени подготовить годную стаью надо много, сил — не меньше. На данный момент у меня тупо нет столько времени и сил) К вашему сведению эт не достижения, а всего лишь 1 вопрос)
0
я могу написать свою либу скажем для AVR, что ща и делаю на дипломе. именно её я и могу выложить. Отсальное, что делал на работе касательно реализаций — не могу.
0
хех) ого сложность)))) круто) даж на AVR такая подпись взломается быстрее чем я чихну
+2
Ну это типа пример, для него такая сложность нормальна. В ролике вон вообще ключи — «52» и «24» Главное — суть правильно показать, чтобы оно не имело принципиальных уязвимостей, а битность всегда можно нарастить до требуемой. Впрочем, как раз с сутью-то и проблемы…
+2
Ну, насколько я знаю, ЭЦП (по крайней мере некоторые варианты) базируется на асимметричном шифровании с открытым ключом расшифровки и закрытым ключом зашифровки, при этом шифруется или документ (чьим публичным ключом расшифровался — тем и зашифрован) или хэш от него (в этом случае хэш расшифровывается публичным ключом и сверяется с хэшем документа).
+1
a9d, ну ты и отжег) e_mc2 всё правильно говорит. а кое-кому следовало б перестать троллить и почитать хотя бы вики
+2
В данном случае совет: делать статьи такого общего обзорного толка типа дайджестов, т.е. обзоров хороших популярных статей специалистов (для начинающих) и более серьезных работ, для тех кто идет или пойдет дальше в этом направлении.

Поясните, плиз, какого рода статьи «общего обзорного толка» Вы хотели бы видеть. По дифференциальному/линейному криптоанализу отдельных алгоритмов? Сомневаюсь, что это кому-то здесь интересно. Как по мне – наиболее актуально базовое описание алгоритмов КЗИ и примеры реализации стандартных криптоалгоритмов.
0
Да теорию и пример реализации алгоритмов при необходимости нагуглить можно, написал бы кто статью о использовании смарткарт для оффлоада криптографии с мк.
0
Ух, сразу 2 статьи по шифрованию. Хорошо, но хотелось бы обратить внимание на одну существенную деталь — сложность. Даже на 32 битных контроллерах работа с длинными (большими) простыми числами не тривиальна, про 8-битки я вообще молчу. Но в свете последних лет и тенденций — направление верное. Я имею некоторое отношение к безопасности, так вот, даже делая что-то для себя большее чем поиграться 5 минут и выбросить — я бы включил туда шифрование — касается обмена по проводным и радиоканалам. Пусть простейшее — симметричное, но включил. В будущем это поможет убить сразу как минимум двух зайцев:
— обеспечить конфиденциальность ( да, вывод очевиден) если поделка выйдет из стадии пеленок, и пойдет в народ. Такое, согласитесь, встречается ;)
— обеспечить целостность передаваемой информации
0
Вообще, складывается, на мой взгляд странная и парадоксальная ситуация. О хакерах и всех их разновидностях применительно к компам и ИТ в целом, говорят уже очень давно. При всем этом в электронике, например, тех же пресловутых сигнализациях, асимметричное шифрование применяется не так что-бы очень уж давно. (вот тут могу обмануть, если есть кто поближе к автосигналкам, возможно поправят). В остальном защита и кодировка взламывается методом медитации и пристального взгляда в перехваченный трафик. Не 100% но около того. Возможно у меня такое мнение сложилось ошибочно, в силу очень сильной закрытости подобного рода информации и, нежелания (вполне себе объяснимого) специалистов идти на подобного рода откровения. Может кто поближе и побольше в курсе подскажет. Я с крупными АСУ(П) не сталкивался. Зато с сигналками чуток ковырялся, ну и опять же повторюсь, больше читал :)
0
ДА я тебе больше скажу, подавляющее большинство PLC контроллеров вообще не используют шифрование или какую либо защиту. Да там типо есть пароль на слив прошивки, но ломается часто он за пол часа тупым RS232 сниффером ибо идет совершенно открытым текстом, либо тупо брутфорсится за пару часов, или защита там ну совсем детская.
easyelectronics.ru/rabochie-budni-xachim-plc.html
вот эту игрушку я вскрыл за 15 минут.
0
Это точно! Я по роду деятельности программист (ПЛК) в области АСУТП. Промышленные ПЛК и вообще все оборудование для АСУ сильно отстает, протоколы тридцати-сорокалетней давности, все в открытом виде. Иногда аж страшно становится. Про всякие RS485/232 я вообще молчу, так по Ethernet в подавляющем большинстве случаев тоже шифрования нет, хужу того, иногда по халатности бывает, что в промышленной сети Ethernet сидит wifi точка с WEP (тут вообще проблем нет взломать), да даже WPA/WPA2, это можно на машине подъехать к заводу за 1 км, направленной антенной +100500 dB захватить пакеты, потом в уютном месте пару месяцев подбирать ключ. А что потом можно устроить на производстве, зная ключ и получив доступк к ПЛК управления процессами, почти всегда потенциально опасными… страшно подумать.

Да что далеко ходить — есть среда разработки от Сименса Step7 называется, там можно создать блоки типа защищенные (от воровства кода). Сименс это громко называет KNOW_HOW_PROTECT. Так чтобы ее снять и посмотреть как сделан блок надо всего-то запустить Microsoft Access, открыть файл базы данных проекта и тупо в одной колонке поменять 1 на 0. Жесть, правда!?
0
Простите конечно за излишнюю эмоциональность, но иногда кажется, что промышленную электронику и ПО (всякие СКАДА-системы и т.д.) делают одни дебилы. Там столько ошибок и недочетов, после них Visual Studio, Quartus, LabView, Keil просто божественные среды! Зато стОит это все просто заоблачно.
Вы бы видели, как глючит Сименсовская СКАДА WinCC за 100500 евро. Как в промышленных ПЛК ошибаются при разводке платы, перерезают дорожку и подпаивают проводком (на заводе в смысле). Как крупные производители путают на шильдиках полярность и 24 В с 220. Как гиганты пром электроники припаивают переключатели наоборот. Примеров у меня много.
0
Точняк! Недавно запускали защищенную DLL продаваемую за 3 000 (три тысячи) баксов. Сломалось простым NOP на месте команды JMP под отладчиком. Использовалось в крутом оборудовании и продавалось отдельно. Так, что это тренд такой в промышленности.
0
Для лицензионной защиты подобных вещей это нормально. Там основная защита юридическая, а не техническая. Вот дырявая безопасность — это уже хуже.
0
Да, тоже такое было — одно ПО за пару кило$ привязывалось к серийному номеру тома жесткого диска, тоже вылечилось NOP'ом.
0
С зашитой программ на ПК есть проблема – программа выполняется в неконтролируемой среде. Проще говоря, программа не может быть уверенна в том, что собственно она сама не была предварительно модифицирована, либо в том, что не перехвачены стандартные функции ОС, которые она использует. Можно очень усложнит взлом (прибегая к разным ухищрениям, типа детекции отладчиков, шифровании собственного кода) но «не взламываемой» программы для ПК быть не может. Вопрос только в том, сколько «хакер» потратит времени на обход защиты.

Поэтому, как правильно заметил Vga , основной упор на юридическую защиту. Некоторые производители ПО отказались от зашиты на уровне софта в принципе.

Например, БД ORACLE. Там нет никакой защиты, ни ключей активации, ни чего подобного, хотя сам софт стоит немерено. Они полагаются исключительно на юридический аспект.
0
Согласен с вами. Процент взолманных продуктов в АСУ ничтожно мал, чтобы заморачиваться, это же не Windows.

Вообще все эти «защиты» даже мешают. У нас был один объект, там было ПО — OPC Server для Modbus. Matrikon'овский. Все официально, лицензионный, не дешевый, как обычно. Все установили, все работает. А на сервере было несколько сетевых и одна была отключена (просто Disabled в Device Manager), потом я ее включил. И через сутки понеслось — отваливается Матрикон без предупреждений, не отдает половину тэгов. Короче весь мозг сломал. Откуда мне-ж было знать, что проклятый Матрикон привязывается к MAC-адресу первой попавшейся карты? Об этом в доках не написано конкретно, просто что привязка к Hardware, не, ну ради бога, но я что, теперь новую плату добавить не могу, тем более она была просто программно отключена. Суббота, на сайте у них висит 24/7 поддержка, а по факту автоответчик на всех номерах. Дошла до меня причина только спустя несколько часов мучений (я еще в RAID массиве диск менял, поэтому сначала думал к нему привязана лицензия была, про сетевую даже не предполагал поначалу), потеряли данные мы за это время. А ПО даже про лицензию не говорило, просто глючило. С тех пор я компанию Матрикон люто-бешено ненавижу и никому не советую.
0
раскрыть комментарий
-5
«К людям нужно относиться мяхше, на жизнь смотреть ширше..» (с) непомню кто =)

Иногда, собранное из доступных источников, пропущенное через своё понимание и поданное в доступной форме с аккуратно раставленными акцентами — иногда оно вполне стоит отдельной статьи. И ничего зазорного в этом нет.

Это может сильно помочь тем, кто ещё только начинает свой поиск на эту тему. Может конечно и не… А может и помочь.
+3
Аркадий Райкин, не?
0
точно, он =)
0
Мы взяли накопипастили чужих ошибок + добавили своих и получили
пропущенное через своё понимание и поданное в доступной форме с аккуратно раставленными акцентами
Прежде чем писать статью, подумайте, хорошо ли Вы сами разбираетесь в вопросе.
0
Мы взяли накопипастили чужих ошибок + добавили своих и получили

Что именно Вас смущает в данной статье. Если есть ошибки – давайте обсудим, я с удовольствием их исправлю (сама статья не претендует на «срыв покровов», она достаточно водянистая и, по этому, я долго сомневался, стоит ли ее публиковать).

Исходя из Ваших соображений, единственной правильной «статьей», например, по AVR является официальный даташит по AVR от Atmel. А любая другая статья (или пример кода) по данному семейству МК – это «накопипастили чужих ошибок + добавили своих и получили». Но Вы, наверное, слышали о таких вещах как «порог вхождения», «доступность изложения материала» и т. д.

ИМХО, именно «разжёванные» статьи являются балле полезными для «новичка», а именно на них я и ориентировался при написании статьи (я сомневаюсь, что данный ресурс посещают специалисты по криптоанализу).
+2
… криптографический алгоритм, да с ошибками, никто никогда не расшифрует :)))
0
О да. Тут ещё ничего, а у a9d статья просто вредительская — там дофига не то что бы ошибок, но умолчанию, которые скорее всего приведут к тому, что реализация будет дырявая как решето, хотя в самих базовых алгоритмах («примитивах» как принято говорить у криптографов) ошибок и не будет.

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

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

Не пишите криптографию сами! НЕ ПИШИТЕ КРИПТОГРАФИЮ САМИ!

А если пишете — почитайте хоть пару толковых книжек, а не статьи в интернете! Ну или вот курс на Курсере — все видео и слайды доступны в архиве курса. Нужен английский, конечно. Но по мне — знание английского важнее всей физики, математики и электроники и начинать надо вообще с него :)
0
Ну или вот курс на Курсере — все видео и слайды доступны в архиве курса.
Линк чтоль приведи.
0
Так. Я был наивен. Тем, кто курс не брал, архив не показывают :(
Интересно, нет ли торрент-трекера, где выкладывают материалы курсов анонимно :)
Я бы выложил — но вот совсем в открытую стрёмно всё же.
0
Есть. Любой публичный трекер, та же пиратская бухта (если она еще работает...). Или на файлообменник.
0
Я выложу в бухту сегодня ночером и дам тут ссылку.
0
Что-то не видно прогресса…
+1
Голова дырявая. Вот, скачал слайды и субтитры и выложил:

thepiratebay.se/torrent/8064748
+1
скорее всего приведут к тому, что реализация будет дырявая как решето

Не пойму, что Вас так смущает в собственной реализации некого (стандартного) криптоалгоритма.

Если бы Вы сказали что «изобретение» (придумывании) собственного криптоалгоритма это плохо — я бы Вас поддержал двумя руками. Я несколько раз (в комментариях к другим статьям) писал, что выдумывание «Собственного Секретного Алгоритма Шифрования» — это очень плохая идея, намного лучше использовать существующие алгоритмы. И о том, что современная криптография не рассматривает всерьез защиту, основанную на «незнании алгоритма» и т. д.

Но я не вижу проблем в собственной реализации стандартного криптоалгоритма. Да, при реализации можно «налажать», сделать ошибку – но это касается абсолютно любого алгоритма. Ошибку можно сделать при реализации сортировки пузырьком или при реализации бинарного поиска.

Иногда (особенно в контексте МК) имеет смысл реализовать криптоалгорим самостоятельно.

Например, тот-же ГОСТ 28147 можно реализовать несколькими способами, можно «развернуть» S-блок, тем самым ускорив алгоритм но это потребует дополнительных затрат по памяти. Можно не разворачивать.

О да. Тут ещё ничего …

Ну, и на том спасибо :)
0
Не пойму, что Вас так смущает в собственной реализации некого (стандартного) криптоалгоритма.
То, что сам базовый алгоритм — математическая абстракция. Он не нужен «сам по себе в вакууме». Нельзя использовать AES128, скажем. Можно использовать CBC-AES или ECB-AES или CTR-AES. Но и это не всё. Использовать алгоритмы шифрования без авторизации — очень плохая идея (очень, очень плохая). Т.е. надо уже добавить что? Надо добавлять MAC. Как добавлять будем? Какой? Итого получается бутерброд, где каждая часть может быть реализована без ошибок (а что такое «без ошибок»? Разная скорость работы на разных ключах, при всегда верном результате — это вот ошибка? Как её отлавливать неоптыный человек, пусть и аккуратный программист будет?), но клей будет течь, увы.

Такое сплошь и рядом — все алгоритмы реализованы верно, а дыры на стыках. Причём дыры не алгоритмические, а чисто технические — если рассматривать алгоритмы как математические сущности, то они все правильные, и код их реализует с математической точки зрения правильно, а результат — решето.

Но я не вижу проблем в собственной реализации стандартного криптоалгоритма. Да, при реализации можно «налажать», сделать ошибку – но это касается абсолютно любого алгоритма. Ошибку можно сделать при реализации сортировки пузырьком или при реализации бинарного поиска.
Да, но эти ошибки отлавливаются тестированием — ручным, автоматическим, бета-тестерами, матерящимися пользователями. Ошибки в реализации СИСТЕМЫ шифрования (а не подлежащих алгоритмов) отловит ваш враг.

И тут есть ещё одна тонкая разница: ошибка-то будет не в алгоритме. Все мыслимые тесты будут проходить, тестовые вектора шифроваться безупречно, все краевые случаи будут обработаны, etc. Но она будет. В невинном сообщении об ошибке, которое будет разным для двух разных ситуаций, например.
А человек, не посветивший изучению криптухи хотя бы пару лет даже не поймёт, где он ошибся (и формально, с математической и обще-программитской точек зрения его код будет безупречно правильным и аккуратным).
С пузырьком или бинарным поиском такой род ошибок невозможен.

Иногда (особенно в контексте МК) имеет смысл реализовать криптоалгорим самостоятельно.
Да, увы, OpenSSL или NaCL на МК не очень-то портируешь, факт. Это серьёзный аргумент.
Но я бы, если шифрование было вовсе критично в проекте, брал бы микроконтроллер, к которому есть родная библиотека, причём лучше бы сертифицированная, например, МастерКардом и/или Визой для применения в термианалах — такие есть, например, у NXP в линейке LPC. Да, думаю, у всех есть, просто каталог NXP я изучал наиболее плотно (остановились на использовании внешнего криптомодуля SAM AV2 от них же).

Тут правда возникает другая засада — всё это часто идёт только под NDA, так как до сих пор есть экспортные формальности. Но для фирмы этот NDA подписать не проблема, как оказалось.

Частнику плохо.
0
Нельзя использовать AES128, скажем. Можно использовать CBC-AES или ECB-AES

Я понимаю, о чем Вы говорите, но я не согласен со столь критическими заявлениями. Зашита, обычно, коррелируется со степенью важности (секретностью, если мы говорим о шифровании) информации. Например, можно реализовать шифрование/ЭЦП, с любой длинной ключа. Хоть несколько миллионов бит. Только, на существующей аппаратной базе, при такой длине ключа выполнение критоалоритма займет очень много времени. Стоит ли оно того? Зависит от ценности информации/убыткам от потенциальной атаки.

Например, можно реализовать достоверный алгоритм двухсторонней аутентификации для открытия входной двери в квартиру с длинной ключа over 9000 бит. Это круто, только среднестатистический МК будет рассчитывать/проверять подпись несколько часов. Имеет ли это смысл? Можно привести другой пример, когда использование ключа такой длинны будет оправданно.

Использовать алгоритмы шифрования без авторизации — очень плохая

Все зависит от того, что вы хотите получить. Шифрование обеспечивает защиту от НСД, ЭЦП (MAC – как частный случай) – гарантирует аутентичность, целостность и неортекаемость. Часто эти методы используются комплексно, но иногда достаточно только одного из них.

Такое сплошь и рядом — все алгоритмы реализованы верно, а дыры на стыках.

Согласен, атаки в основном делают на реализацию, а не на алгоритм. Но чаще даже не на реализацию самого криптоалгоритма, а на реализацию софта в целом (банальное переполнение буфера и т. д.)

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

Шифрование обеспечивает защиту от НСД, ЭЦП (MAC – как частный случай) – гарантирует аутентичность, целостность и неортекаемость.
Проблема в том, что есть довольно много атак, построенных на подсовывании мусора для расшифровки. Если у нас нет MAC — то мы не можем сказать, надо ли это вообще расшифровывать…
0
Если у нас нет MAC — то мы не можем сказать, надо ли это вообще расшифровывать…

Да, ели мы говорить о серьёзных средствах шифрования, то устройство должно блокировать попытки пропустить через него «левый» поток информации, иначе можно накопить достаточную базу для дифференциального криптоанализа (либо тупо использовать «брутфорс», хотя, в случае современных алгоритм, это не эффективно). Но сомневаюсь, что эти вопросы актуальны в рамках данного сообщества.
0
www.ti.com/lit/ds/symlink/cc2510f32.pdf глава «12.12 AES Coprocessor». Спасибо за придирки к AES в статье о RSA.

Алгоритм RSA я взял стандартный. В нем есть ошибки? Не устраивает длина ключа? Не устраивает, что я использую таблицу простых чисел в своем частном случае?
0
А ведь обсудить всё это можно было прямо там…

Зачем писать сначала: «коменты запрещены. Они меня не интересуют.», а потом в стороннем топике вопрошать, что именно не устраивает в статье?
+2
вот поэтому я их и запретил!
-3
Пару лет назад я собирал LibTomCrypt (+TomsFastMath) для STM32 и баловался с реализованными в этой замечательной либе криптоалгоритмами. Все возможные хэши, симметричные алгоритмы шифрования, MAC — работали «на ура» с достаточной производительностью (к сожалению, точных результатов нет, но я был очень удовлетворён полученным результатом).

Работал и RSA со 128-битным ключом. Правда, пришлось много памяти (из 64К, имеющихся на борту микроконтроллера) зарезервировать под стек и хип, но, тем не менее, оставалось достаточно ресурсов для пользовательской программы.
Работал и парсер сертификатов, и даже верификация цепочек сертификатов (пробовал только с PKCS 1). Всё выполнялось за вполне разумное время.

Единственное, что не получилось испытать — это генерацию ключей. К сожалению, реализованный в библиотеке алгоритм хотел очень много как хипа, так и стека. Ну и аппаратного генератора случайных чисел у меня не было, использовал только программный и часы как источник энтропии. Но эта проблема, в принципе, вполне решаема с помощью генератора шума, АЦП и хэш-функции.

Тем не менее, если пары ключей и сертификаты сгенерировать заранее и прошить в устройства, то RSA-128 вполне применим для практического использования в 32-разрядных однокристаллках для взаимной верификации устройств и безопасной генерации сессионного ключа для какого-нибудь симметричного алгоритма. Вполне возможно, например, сделать автосигнализацию с прекрасно защищённым двусторонним каналом связи.

Было у меня желание пощупать ещё и алгоритм ECC (Elliptic Curve Cryptography), тоже имплементированный в LibTomCrypt, который который считается намного более криптостойким, чем RSA, при той же длине ключа. То есть, при той же криптостойкости вычисления будут занимать в разы меньше времени. Но руки не дошли, к сожалению.

Возможно, после ваших статей вернусь к теме. Ведь интересно же! :)
0
А сколько времени занимает взлом RSA-128? Как я понимаю, из-за особенности генерации ключей эффективная длина ключа гораздо меньше, примерно 2*log2(кол-во 64-битных простых чисел)?
И сколько времени требуется на взлом RSA-32, как у a9d?
Было у меня желание пощупать ещё и алгоритм ECC (Elliptic Curve Cryptography), тоже имплементированный в LibTomCrypt, который который считается намного более криптостойким, чем RSA, при той же длине ключа.
Забавно, но раньше я почему-то думал, что RSA как раз на основе эллиптических кривых)
0
Считается, что RSA-128 взломать за разумное время, в принципе, можно, поэтому эта длина ключа вообще нигде и никогда не используется. Насколько помню, даже в исходниках LibTomCrypt минимальная длина ключа ограничивалась 512 битами, так что пришлось править руками какой-то хедер перед билдом. Но ведь для простых применений мы вполне можем допустить, что кто-то сможет найти секретный ключ за год вычислений на суперкомпьютере, правда? :)

Нет, ECC это другой алгоритм. И криптостойкость 160-битного ключа в нем считается равной криптостойкости 1024-битного ключа для RSA.
0
Нет, ECC это другой алгоритм. И криптостойкость 160-битного ключа в нем считается равной криптостойкости 1024-битного ключа для RSA.
Да я уже вижу)
А криптостойкость RSA низкая потому, что из 2^1024 степени теоретически возможных 1024-битных ключей реально для RSA подходят только 2^160, являющиеся произведениями простых чисел?
0
Ролик крутой! Да, инет — это все-таки сила. Еще бы таблетки какие бы изобрели или еще что, что бы быстро всасывать в мозг огромные массы серой справочной инфы (например, даташиты и прочие руководства).
0
ноотропы=)
0
Немного интересуюсь этой тематикой.
Интересно пробовал кто-то в таком роде что делать в Matlab, Simulink.
Я нашел исходник RSA для Matlab, разобрался в нем, но он просто шифрует-дешифрует, сейчас думаю как бы сделать какой-то обмен между двумя машинами(хотя смоделировать все ето).
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.