Шифрование

[roman.com]

А давайте подумаем вместе))

Есть сеть на AVR... и другие устройства...

схема.jpg

(178.13 KiB) Скачиваний: 77

Все AVR и другие устройства обмениваются данными по сети с шифрование AES256.

Проблема: где хранить... как передавать... следить чтобы не украли... ключи шифрования AES256 ?

Поделитесь своим опытом... мыслями.

[AlexS4]

есть асимметричные алгоритмы с публичным ключем применяется широчайше: pgp, ssl сертификаты для https (tls), ssh-auth, dkim, ...
в случае когда поток данных микроскопический и задача облегчения и перехода на симметричные сессионные ключи не стоит, то все тривиально: можно просто шифровать данные или подписывать команды своим секретным ключем и публичным ключем приемника. а сами публичные ключи публиковать на нешифрованных сервисах или пресетить статически.

из современных протоколов: rsa, eca(напр ed25519)

[roman.com]

pgp, ssl сертификаты для https (tls), ssh-auth, dkim,... rsa, eca(напр ed25519)

как это сделать на ATmega328 ? с объёмом памяти RAM = 2048 байт ? пока не представляю...

поток данных микроскопический... в основном передаются команды управления... от силы пару сотен байт...

[AlexS4]

значащая часть публичного ключ для ed25519 это всего 45 байт. а секретные ключи конечно должны пресетиться(хардкодиться). вроде должно быть реально. епп надо ram ~x3 шифруемого массива + ~ 100 байт на загружаемый чужой публичный ключ и переменные.

[roman.com]

помедленней пожалуйста...)) я с такими протоколами ещё не работал...
https://ru.wikipedia.org/wiki/EdDSA#Ed25519

https://ru.wikipedia.org/wiki/PGP#Механизм_работы_PGP
что-то сложновато...
надо по-проще...

ssl сертификаты - говорят устарел...
на смену пришёл TLS 1.2 и TLS 1.3... сертификаты...

[AlexS4]

нене, устарели протоколы обмена ssl, tls пришли им на смену а концепция ssl сертификатов и инфраструктуры x509 нисколько не устарели, но вам они не нужны.

смотрите сразу ed25519 но по нему мало популярных текстов, посему надо вначале прочитать про rsa (просто для общего знакомства).
и SHA224/256

проще и чтоб "не устарело" я не знаю

и надо понимать что если мы полностью делаем комплект оборудования и нет задачи обьединять оборудование разных производителей
то задача схлопывается до генерации одного общего секретного ключа (psk) скрытого внутри кодоа и одинакового для всего комплекта (создаваемого например при компиляции) и любых простых симметричных алгоритмов, хоть aes хоть blowfish.

[roman.com]

теперь медленно и по порядку...


Рассмотрим как работает шифрование TLS 1.2... на примере сайта https://radiokot.ru

DNS запрос

радиокот_89.108.124.75.jpg

(131.35 KiB) Скачиваний: 28

IP = 89.108.124.75

подключаемся к серверу https://radiokot.ru по HTTPS...

0- сервер передаёт сертификат...

сертификат.jpg

(42.51 KiB) Скачиваний: 31

1- передаём список методов шифрования TLS 1.2...
2- сервер https://radiokot.ru выбирает из списка методов шифрования TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256...
3- подтверждаем выбор...
4- далее обмен данными с сервером https://radiokot.ru по HTTPS...

HTTPS.jpg

(181.57 KiB) Скачиваний: 23

осталось разобраться с этим:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

алгоритм Диффи-Хеллмана на эллиптических кривых, аутентификация сервера будет производится с помощью ECDSA, а в качестве алгоритма шифрования трафика будет использоваться AES с длиной ключа 128 бит в режиме GCM. В качестве алгоритма MAC используется SHA256.


из всего что тут написано я знаю только AES_128
запихнули в ATmega328 AES_128/256

AES_128.txt

(20.54 KiB) Скачиваний: 24

AES_256.txt

(23.63 KiB) Скачиваний: 18

~половину памяти ATmega328 съели))

а остальное ?

и как остальное я запихну в ATmega328 ?

[AlexS4]

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

для вашей задачи нужен
1. любой из алгоритмов SHA2 https://en.wikipedia.org/wiki/SHA-2 под avr.
2. софт генерирующий пары ed25519 например ssh-keygen (врядли вам нужна именно генерация ключей на avr )
3. при сборке хекса сгенерить и добавить эту пару ключей в кодовую флэшку вместе с кодом.
4. в коде каждой из нод должен быть сервис публикации публичного ключа вашего уникального девайса, любым удобным протоколом, хоть http отдавать его на запрос get /key.pub или dns txt скажем.

[roman.com]

1-ECDHE
понятия не имею как это делается)) надо вспоминать вышку...
2-ECDSA
режим...
3-AES_128
работает))
4-GCM
имитовставку (MAC) в принципе добавить можно... не уверен нужно ли))

GCM.jpg

(41.53 KiB) Скачиваний: 28

5-SHA256
в принципе сделать можно... надо подумать))

сертификат кроме публичного ключа содержит инфоблок.

угу))

Screenshot_1.jpg

(34.45 KiB) Скачиваний: 27

Screenshot_2.jpg

(164.32 KiB) Скачиваний: 25

публичный ключ... обычно 1024-4096...
у кота 2048...

Screenshot_3.jpg

(163.9 KiB) Скачиваний: 24

и т.д.

как всё запущенно то))


Добавлено after 10 minutes 15 seconds:
короче... надо выкинуть всё лишнее... чтоб всё влезло в ATmega328... при сохранении криптостойкости и надёжности.
вот такая простая задача.))


Добавлено after 1 hour 6 minutes 7 seconds:

AlexS4 писал(а):

1. любой из алгоритмов SHA2 https://en.wikipedia.org/wiki/SHA-2 под avr.
2. софт генерирующий пары ed25519 например ssh-keygen (врядли вам нужна именно генерация ключей на avr )
3. при сборке хекса сгенерить и добавить эту пару ключей в кодовую флэшку вместе с кодом.
4. в коде каждой из нод должен быть сервис публикации публичного ключа вашего уникального девайса, любым удобным протоколом, хоть http отдавать его на запрос get /key.pub или dns txt скажем.

1. пока не знаю зачем...
2. не понял ...
3. при сборке хекса сгенерить и добавить эту пару ключей в кодовую флэшку вместе с кодом.
вшили во все МК и устройства ключи...

схема.jpg

(196.5 KiB) Скачиваний: 31

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

4. не понял ...

[Муркиз]

У вас, что, передача данных мирового уровня , чтобы использовать международные стандарты ?
Своя частная сеть ? Ну так просто возьмите и переставляет байты ( биты) при передаче / приеме по определенному правилу. Нынешним массовым хакерам даже с таким кодированием не справиться...

[roman.com]

да, у меня передача данных мирового уровня... работает по интернету.

AES_256.txt

(23.87 KiB) Скачиваний: 42

[Муркиз]

Тады ой !

[roman.com]

далее... упростим алгоритм шифрования.
1- уберём имитовставку (MAC)... и сделаем простой блочный шифр без вставок))
шифрование в режиме счётчика...

нет_GCM.jpg

(41.17 KiB) Скачиваний: 34

2-добавим генератор случайных чисел для повышения энтропии...

ген_нет_GCM.jpg

(41.9 KiB) Скачиваний: 32

всё работает))

AES_256.txt

(24.68 KiB) Скачиваний: 20

далее... имитовставка (MAC)
как написано в справочнике...
"имитовставка (MAC) нужна для аутентификации открытых данных прикреплённых к сообщению..."
у нас нет "открытых данных прикреплённых к сообщению..."
поэтому имитовставка (MAC) нам не нужна...

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

значит добавим сессионные ключи...

AES_256.txt

(25.01 KiB) Скачиваний: 17

теперь все устройства сами генерируют сессионные ключи...

ключи.jpg

(12.09 KiB) Скачиваний: 30

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

схема.jpg

(203.16 KiB) Скачиваний: 29

работает))

roman.com писал(а):

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

алгоритм Диффи-Хеллмана на эллиптических кривых, аутентификация сервера будет производится с помощью ECDSA, а в качестве алгоритма шифрования трафика будет использоваться AES с длиной ключа 128 бит в режиме GCM. В качестве алгоритма MAC используется SHA256.

для обмена сессионными ключами можно использовать ECDHE... но есть две проблемы.
1. публичный ключ... 4096... в ATmega328 не влезет...
2. по заявлению учёных через ~5 лет ECDHE будет взломан))

https://www.youtube.com/watch?v=f5slLeCz7p8

а зачем нам использовать шифры... которым жить осталось не долго))


SHA256 в ATmega328 влезет... но я не уверил нужен ли он нам...
с одной сторы SHA256 повышает надёжность...
с другой стороны возрастает вычислительная сложность... увеличивается время передачи... и другие ресурсы ATmega328.


и последнее...

https://ru.wikipedia.org/wiki/AEAD-режи ... шифрования

"Важно, что и AE-схемы, и AEAD-схемы требуют использования nonce. Это необходимо для обеспечения семантической безопасности (невозможность злоумышленника при многократном использовании схемы под одним и тем же ключом получить отношения между сегментами зашифрованных сообщений), а также для защиты от атаки повторного воспроизведения, при которой злоумышленник под видом легального пользователя повторно отправляет сообщение. Генерация nonce и использование его только единожды ложится на ответственность отправителя. Для этого можно использовать, например, счетчик."

-для семантической безопасности будем использовать сессионные ключи.
-для защиты от атаки повторного воспроизведения будем использовать счетчик.

теперь другая проблема))
вместе с ключами ATmega328 должна ещё хранить и счётчик... а где его хранить ?))

-в рабочем режиме счётчик хранится в RAM...
при отключении питания счётчик обнуляется.. .и вся безопасность летит коту под хвост))
-можно перед отключением питания сделать автосохранение в EEPROM... но это усложнит схему и снизит надежность...
-ещё варианты...


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

а что нам подсказывает справочник ?

справочник предлагает нам использовать Nonce...

https://ru.wikipedia.org/wiki/Nonce

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

Во ! Замечательная идея)) ATmega328 это умеет. Так и сделаем. ))

для большей безопасности можно ещё добавить метку времени... чтобы обеспечить уникальность nonce для сеанса аутентификации...
только с этим будут проблемы... т.к. у ATmega328 нет системных часов))
зато у всех гаджетов есть системные часы...


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

замечательно)))

[roman.com]

roman.com писал(а):

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

а что нам подсказывает другой справочник ?
"Если вы отправите клиенту секрет для шифрования пароля, перехватчик сможет перехватить его и расшифровать пароль на обратном пути."

[roman.com]

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

собственно вся проблема сводится только к генерации уникального вектора...

что-то больше ничего пока на ум не приходит))

[AlexS4]

roman.com писал(а):

roman.com писал(а):

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

а что нам подсказывает другой справочник ?
"Если вы отправите клиенту секрет для шифрования пароля, перехватчик сможет перехватить его и расшифровать пароль на обратном пути."

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

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

[roman.com]

В 1913 году Армстронг описал систему приемника...
В 2023 году супергетеродинам исполняется 110 лет))
и ничего нового за 110 лет не изобрели))

а криптография - это молодая наука.
каждых несколько лет появляются новые протоколы... и что вчера считалось криптостойким... сегодня уже нет))

а в 2023 весь мир уже потихоньку переходит на квантовую криптографию...

передать зашифрованный секрет для проверки и передать перехватываемый секрет это 2 большие разныцы.

и как мы будем передавать секрет ?

допустим есть у нас SHA256... и как с его помощью мы будем передавать секрет ?

[roman.com]

допустим есть у нас SHA256... и как с его помощью мы будем передавать секрет ?

никак))
в нашем случае хеш SHA256 бесполезен...

обычно хеш SHA256 используют для проверки ошибок в блоке данных...

Screenshot_2.jpg

(40.5 KiB) Скачиваний: 26

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

Screenshot_1.jpg

(30.88 KiB) Скачиваний: 24

а так же для хранения паролей пользователей... обычно на сервере...

Screenshot_5.jpg

(31.9 KiB) Скачиваний: 20

и т.д.
но в нашем случае сам по себе хеш SHA256 бесполезен...
поэтому к хеш SHA256 добавляют ключ... и получают электронную подпись))
например так делают в блокчейн...

Screenshot_3.jpg

(62.38 KiB) Скачиваний: 23

хеш SHA256 + ключ... получают длинные цепочки... блокчейн...))

Screenshot_4.jpg

(21.8 KiB) Скачиваний: 21

Добавлено after 57 minutes 32 seconds:
сделаем аналогичным образом...
с той лишь разницей что в блокчейн можно читать блоки но нельзя изменить блоки... без ключа... и с ключом нельзя)) потому что это блоки))
и у нас тоже нельзя изменить блоки... потому что их нельзя прочитать... без ключа...))

ещё добавим системное время...

схема.jpg

(212.03 KiB) Скачиваний: 30

получился 3-х колёсный велосипед)) можно ехать майнить крипту))


с часами криптостойкость грубо 1/2^256...
без часов криптостойкость грубо 1/2^128...

1/2^128 хорошо... но 1/2^256 лучше ))
надо подумать как добавить часы в МК.

[roman.com]

продолжаем совершенствовать))

-асимметричные алгоритмы с публичным ключем... рассматривать не будем.. они доживают свой век... ))
-SHA256 избыточен...
-GCM это нормальное решение))

GCM.jpg

(41.17 KiB) Скачиваний: 17

Добавлено after 15 minutes 15 seconds:

roman.com писал(а):

далее... упростим алгоритм шифрования.
1- уберём имитовставку (MAC)... и сделаем простой блочный шифр без вставок))
2-добавим генератор случайных чисел для повышения энтропии...

генератор случайных чисел для повышения энтропии... - избыточно))
это не добавляет криптостойкости))

roman.com писал(а):

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

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

сессионные ключи... - избыточно))

сам обмен сессионными ключами использующий общий секретный ключ...
это не добавляет криптостойкости))

roman.com писал(а):

алгоритм Диффи-Хеллмана на эллиптических кривых

алгоритм Диффи-Хеллмана на эллиптических кривых... - избыточно))
это не добавляет криптостойкости))

roman.com писал(а):

-для семантической безопасности будем использовать сессионные ключи.

не будем))
сессионные ключи будем вводить вручную))
это добавляет криптостойкости))

roman.com писал(а):

-для защиты от атаки повторного воспроизведения будем использовать счетчик.

-для защиты от атаки повторного воспроизведения будем использовать счетчик + системное время.
это добавляет криптостойкости))

key.jpg

(117.53 KiB) Скачиваний: 10

roman.com писал(а):

вместе с ключами ATmega328 должна ещё хранить и счётчик... а где его хранить ?))

-в рабочем режиме счётчик хранится в RAM...
при отключении питания счётчик обнуляется.. .и вся безопасность летит коту под хвост))
-можно перед отключением питания сделать автосохранение в EEPROM... но это усложнит схему и снизит надежность...
-ещё варианты...

справочник предлагает нам использовать Nonce...

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

угу))

[roman.com]

далее...

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

допустим...

выкидываем всё лишнее...

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

так уже лучше))

всё работает))

схема_PoE(5V2A)_AVR.jpg

(171.8 KiB) Скачиваний: 15