ротация HMAC ключа

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

Знакомый юзал эту либу и советовал: https://www.wolfssl.com/wolfSSL/wolfssl-stm32.html

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

http://www.st.com/content/ccc/resource/technical/document/user_manual/34/1a/2...

Эта криптолиба проприетарная. Даже я бы её юзать не стал.

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

Или предавать ключ зашифрованный несиметричным алгоритмом

Не побоюсь показаться лохом, но это не тоже самое ли ?

Та не, пользуюсь mbedtls уже, с этим все в порядке. Интересует не реализация, а сам механизм в крупную клетку - как обеспечить безопасную передачу ключа.

Долго расшифровывается aes ключ?

У mbedtls для каждого алгоритма есть тестирование. Это заняло около 2.5 сек (просто в уме отсчитывал): AES-ECB-128 (dec): passed

AES-ECB-128 (enc): passed

AES-ECB-192 (dec): passed

AES-ECB-192 (enc): passed

AES-ECB-256 (dec): passed

AES-ECB-128 (dec): passed

AES-ECB-128 (enc): passed

AES-ECB-192 (dec): passed

AES-ECB-192 (enc): passed

AES-ECB-256 (dec): passed

AES-ECB-256 (enc): passed

AES-CBC-128 (dec): passed

AES-CBC-128 (enc): passed

AES-CBC-192 (dec): passed

AES-CBC-192 (enc): passed

AES-CBC-256 (dec): passed

AES-CBC-256 (enc): passed

AES-CFB128-128 (dec): passed

AES-CFB128-128 (enc): passed

AES-CFB128-192 (dec): passed

AES-CFB128-192 (enc): passed

AES-CFB128-256 (dec): passed

AES-CFB128-256 (enc): passed

AES-CTR-128 (dec): passed

AES-CTR-128 (enc): passed

AES-CTR-128 (dec): passed

AES-CTR-128 (enc): passed

AES-CTR-128 (dec): passed

AES-CTR-128 (enc): passed

AES-ECB-128 (dec): passed

AES-ECB-128 (enc): passed

AES-ECB-192 (dec): passed

AES-ECB-192 (enc): passed

AES-ECB-256 (dec): passed

AES-ECB-128 (dec): passed

AES-ECB-128 (enc): passed

AES-ECB-192 (dec): passed

AES-ECB-192 (enc): passed

AES-ECB-256 (dec): passed

AES-ECB-256 (enc): passed

AES-CBC-128 (dec): passed

AES-CBC-128 (enc): passed

AES-CBC-192 (dec): passed

AES-CBC-192 (enc): passed

AES-CBC-256 (dec): passed

AES-CBC-256 (enc): passed

AES-CFB128-128 (dec): passed

AES-CFB128-128 (enc): passed

AES-CFB128-192 (dec): passed

AES-CFB128-192 (enc): passed

AES-CFB128-256 (dec): passed

AES-CFB128-256 (enc): passed

AES-CTR-128 (dec): passed

AES-CTR-128 (enc): passed

AES-CTR-128 (dec): passed

AES-CTR-128 (enc): passed

AES-CTR-128 (dec): passed

AES-CTR-128 (enc): passed

Ты не понял намека. У тебя проблема — передать секрет через ненадежный канал — используй RSA. Причем тут скорость? Это одноразовая операция на сессию.

ssh

Выше я очень тонко намекнул

Ранее для передачи этого ключа использовался RSA, но из-за сложности решили отказаться в пользу AES.
Геморройно управлять этим делом (со слов заказчика)

STM32

Но допустим, что комент был бы уместен. Как бы ты сделал ротацию SSH ключей ? Только опять ssh не отвечай, пожалуйста )

Возьми curve25519 для обмена ключами, или сразу используй secretbox из libsodium. А, кстати, почему для тебя Диффи-Хеллман оказался сложным?

RSA, но из-за сложности решили отказаться в пользу AES.

Трусы или крестик. Ты как маленький, прям.

Ну.. да, ты прав отчасти. Но опять же, как их ротацию производить по незащищенному каналу ?

Похоже на правду, судя по описанию. Его раскурю.

как безопасно передать ключ AES по воздуху

1. Ограничить доступ к воздуху(выложить стенки пещеры свинцовыми плитами) 2. занести туда оборудование. 3. Передать ключ. 4. Вынести оборудование 5. Следующие ключи передавать с помощью предыдущих.

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

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

Ну, и асиметричная криптография - её не зря придумывали.

Понял. 1. Свинец какой толщины лучше брать ? 2. Сильно ли влияет зазор между плитами на безопасность ? 3. Достаточно ли 800 м глубины под морским дном, или стоит убедить заказчика разместиться глубже ?

По существу. Только обсуждал с заказчиком curve25519, говорит ок, но имей ввиду: 1) less private key management 2) less computation power even a small ECU can use it.

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

Вопрос на засыпку: вообще есть понимание для чего нужен hmac и как его применять?

Хинт: Рандомная соль с устареванием (можно до параноидальны значений 1-2 минут для самоуспокоения) не позволяет своевременно создать «радугу» хэшей - соответственно, такое решение вполне достаточно. Тут главное не статическая рандомная соль.

Ответ: более чем. За хинт спасибо, учту.

hmac следует понимать так:

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

Сервер говорит: слушай слать пароль мне не надо, но посчитай-ка мне с этими параметрами (как правило это соль) для твоего пароля hmac-хэш и вышли его мне, клиент считает и отсылает серверу.

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

Довольно часто, по разным причинам, встречаются решения, где соль практически статическая.

Наиболее стойкое решение пока, это hmac_sha512 + рандомная соль, с устареванием более быстрым чем возможность построения и поиска по «радуге»

В архитектуру желательно закладывать возможность смены алгоритма хэширования в сторону «утяжеления»

В этом случае у Midl-Man-а шансов практически нет ...

И да, соль д.б. одноразовая желательно ;)

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

Была такая мысль.

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

И если ключ MITM'у стал известен, то соль здесь уже не поможет. Надеюсь я правильно понял.

А в чем геморройность того, чтобы управлять (как выразился Ваш заказчик) делами, связанными с асимметричной криптографией?