Тоже хороший вариант, но опять же встает проблема управления ключами (в предыдущих комментариях обсуждалась).
Да и я хотел обратить внимание, что здесь не только флешки (и другие носители) можно так контролировать, а вообще любые перемещаемые внутри периметра предметы, которые могут представлять какую-либо ценность.
для загрузки технологических параметров в оборудование, работающее в изолированных сегментах (например, металлургия, подпадает под приказы № 31 и 239);
для загрузки обновлений ПО в изолированные сегменты (там же).
Правда, придется как-то контролировать, что флешка не исчезла, а в изолированном контуре, например:
с помощью RFID-меток;
с помощью АРМ на входе в изолированный контур, где оператор будет ставить галочку, что флешка здесь, и снимать ее при завершении работы в контуре.
Ну тогда я бы предложил preshared-ключи + симметричное шифрование. Ключи генерить и заливать на АРМ Администратора при регистрации флешек перед раздачей пользователям. Этого будет достаточно для предотвращения MITM.
Поэтому и предлагаю в более функциональной системе использовать специальные носители со взаимной аутентификацией с компьютером. И не подделаешь, и скопировать содержимое "на ходу" не получится.
Иначе действительно без досмотра не обойтись, а хотелось бы избежать.
Увы, подробности разработки ГОСТ Р 34.11-2012 мне неизвестны. Вполне возможно, что и случайна — AES-подобные преобразования есть во множестве хэш-функций.
Думаю, что серьезные исследования проводились. Затронули ли они rebound-атаку — сложно сказать.
Да и расширение атаки до 9,5 раунда было уже после выхода стандарта.
Меня вот больше беспокоят мультиколлизии — это похоже на структурную проблему.
Тоже хороший вариант, но опять же встает проблема управления ключами (в предыдущих комментариях обсуждалась).
Да и я хотел обратить внимание, что здесь не только флешки (и другие носители) можно так контролировать, а вообще любые перемещаемые внутри периметра предметы, которые могут представлять какую-либо ценность.
Я согласен, что это не просто. Распределение симметричных ключей - это всегда отдельная проблема.
А как насчет альтернативного варианта - корпоративная PKI?
А как переносить данные между изолированными контурами?
Да, это снова получается специальный носитель.
Я бы добавил еще тщательную проверку самого обновления перед его применением.
Вот два реальных примера:
для загрузки технологических параметров в оборудование, работающее в изолированных сегментах (например, металлургия, подпадает под приказы № 31 и 239);
для загрузки обновлений ПО в изолированные сегменты (там же).
Правда, придется как-то контролировать, что флешка не исчезла, а в изолированном контуре, например:
с помощью RFID-меток;
с помощью АРМ на входе в изолированный контур, где оператор будет ставить галочку, что флешка здесь, и снимать ее при завершении работы в контуре.
Ну тогда я бы предложил preshared-ключи + симметричное шифрование. Ключи генерить и заливать на АРМ Администратора при регистрации флешек перед раздачей пользователям. Этого будет достаточно для предотвращения MITM.
Да, подмена флешки - самая проблемная часть идеи.
Поэтому и предлагаю в более функциональной системе использовать специальные носители со взаимной аутентификацией с компьютером. И не подделаешь, и скопировать содержимое "на ходу" не получится.
Иначе действительно без досмотра не обойтись, а хотелось бы избежать.
Да и расширение атаки до 9,5 раунда было уже после выхода стандарта.
Меня вот больше беспокоят мультиколлизии — это похоже на структурную проблему.