Сергей Панасенко
@SergeyPanasenko
Исследователь в области криптографии и ИБ
Information
- Rating
- Does not participate
- Location
- Зеленоград, Москва и Московская обл., Россия
- Works in
- Registered
- Activity
Исследователь в области криптографии и ИБ
Information
Вы правы, но всё это не отменяет того факта, что очень часто блокчейн сравнивается с БД.
Я на эту тему привел цитату в статье.
А вот здесь: https://habr.com/ru/companies/aktiv-company/articles/760730/ обсуждались схемы выбора технологии хранения данных, где в подавляющем большинстве случаев выбор делался между этими же технологиями.
Получается, что все привыкли думать, что блокчейн - это альтернатива СУБД, просто другая по структуре, набору возможностей и свойствам.
Развернутый ответ обычно интереснее и информативнее.
А если наоборот? У вас классическая СУБД с записью данных, подтверждаемых (прямо или косвенно) третьей доверенной стороной. Доверенная сторона по какой-либо причине перестает существовать. Мне кажется, будет еще хуже :-)
Думаю, что в таком случае блокчейн всё равно можно будет использовать, но вряд ли он останется оптимальным решением. Подобная смена условий вряд ли будет полезна любой системе, а не только блокчейну.
"Forward security" используют не реже, чем "Forward secrecy". Не возьмусь судить, какой из терминов вернее, но используются они взаимозаменяемо и одинаково часто.
Насчет "Упреждающей секретности" - согласен, звучит хорошо и внятно.
Тоже хороший вариант, но опять же встает проблема управления ключами (в предыдущих комментариях обсуждалась).
Да и я хотел обратить внимание, что здесь не только флешки (и другие носители) можно так контролировать, а вообще любые перемещаемые внутри периметра предметы, которые могут представлять какую-либо ценность.
Я согласен, что это не просто. Распределение симметричных ключей - это всегда отдельная проблема.
А как насчет альтернативного варианта - корпоративная PKI?
А как переносить данные между изолированными контурами?
Да, это снова получается специальный носитель.
Я бы добавил еще тщательную проверку самого обновления перед его применением.
Вот два реальных примера:
для загрузки технологических параметров в оборудование, работающее в изолированных сегментах (например, металлургия, подпадает под приказы № 31 и 239);
для загрузки обновлений ПО в изолированные сегменты (там же).
Правда, придется как-то контролировать, что флешка не исчезла, а в изолированном контуре, например:
с помощью RFID-меток;
с помощью АРМ на входе в изолированный контур, где оператор будет ставить галочку, что флешка здесь, и снимать ее при завершении работы в контуре.
Ну тогда я бы предложил preshared-ключи + симметричное шифрование. Ключи генерить и заливать на АРМ Администратора при регистрации флешек перед раздачей пользователям. Этого будет достаточно для предотвращения MITM.
Да, подмена флешки - самая проблемная часть идеи.
Поэтому и предлагаю в более функциональной системе использовать специальные носители со взаимной аутентификацией с компьютером. И не подделаешь, и скопировать содержимое "на ходу" не получится.
Иначе действительно без досмотра не обойтись, а хотелось бы избежать.
Да и расширение атаки до 9,5 раунда было уже после выхода стандарта.
Меня вот больше беспокоят мультиколлизии — это похоже на структурную проблему.