Re: Настоящая криптографическая карта для аутентификации в СКУД (не RFID)
Микрон находится в РФ.
А где делают чип для Rutoken ECP2 Touch?
Какой в нем чип?
Вы не авторизованы. Пожалуйста, войдите или зарегистрируйтесь.
Форум Рутокен → Техническая поддержка пользователей → Настоящая криптографическая карта для аутентификации в СКУД (не RFID)
Чтобы отправить ответ, нужно авторизоваться или зарегистрироваться
Микрон находится в РФ.
А где делают чип для Rutoken ECP2 Touch?
Какой в нем чип?
Пожалуйста, подскажите в общих словах, по какой примерно схеме лучше делать аутентификацию с использованием Rutoken ECP2 ?
Как мне кажется, самое простое хранить на микрокомьютере внутри металлического бокса 2 значения до дешифрования приватным ключом и после, а токен использовать для дешифрования и сравнения результата с хранимым дешифрованным значением? Но не уверен, насколько это безопасно.
Важна ли длина дешифруемого текста? Его энтропия? Наверно, можно сгенерировать случайный текст, подмешивая на вход различные физические параметры типа температурного датчика и т.п.?
Важно ли то, будут ли атакующие заранее знать шифрованное значение и дешифрованное? Можно ли создать некий псевдо крипто токен, который бы поддерживался OpenPGP и просто выдавал бы в связке с PGP нужные значения для сравнения с моими вовсе без дешифрации? Как установить нужные значения внутри микрокомпьютера ARM, чтобы о них никто не знал ни по какому каналу, даже чтением мыслей? Наверно, надо сделать скрипт, который их автоматически генерирует и запускать его каждый раз перед или после постановки, чтобы сравниваемые значение ежедневно менялись? Микрокомпьютер, наверно, нельзя подключать к интернет и даже к локалке.
Если Rutoken ECP2 работает с GPG (PGP), то наверно, через него и шифровать?
Зашифровать открытым ключом могут все, расшифровать только владелец токена, внутри которого, хранится неизвлекаемый приватный ключ. Поэтому какой бы другой токен (с другим приватным ключом) не вставили для дешифрации, он не подойдет, потому что не выдаст после дешифрования нужное значение, хранимое на микрокомпе.
При совпадении значения после дешифрования можно с микрокомьютера коммутировать Dallas button для снятия сигналки с охраны или постановки.
Можно ли снаружи металлического бокса каким-то способом воздействовать на микрокомпьютер внутри бокса и поменять управляющий скрипт для безусловной коммутации Dallas либо поменять сравниваемые значения, хранящиеся в файловой системе SD Card? Есть ли в ARM Cortex A7 Allwinner A20/H3 закладки, аналогичные закладкам X86 (Intel/AMD и т.п.), это даже без Intel ME/PSP, закладка прямо внутри виртуальной машины X86.
Наверно, можно атаковать по каналу PS2 беспроводным способом без прямого подключения вместо клавиатуры PS2? Наверно использование очень древней клавы PS2 поможет избавиться от части современных жучков в клаве. Но без монитора для визуализации и с ограниченным временем на сработку сигналки наверно затруднительно? Но в зависимости от того, кто атакует, не невозможно?
У меня подозрение, что дорогие современные HDD имеют встроенные радиожучки для удаленного управления такими дисками и возможно даже компьютерами при наличии на компе снаружи закрытого софта для рулежки этой закладкой. Даже после отключения от интернет и локалки на сервере видеонаблюдения и закрытой двери на металлическую защелку изнутри у меня избирательно уничтожалось содержимое файлов видеозаписи, находящихся внутри ext4 поверх ZFS без шифрования vdevs. Возможно, шифрование vdevs пула ZFS затруднило бы модификацию JPG файлов ZoneMinder, если модификация происходила изнутри диска из его прошивки. Тогда получается, надо брать самую древнюю карту SD, какую удастся найти, чем старше, тем лучше.
Аутентификацию можно проводить двумя токенами от ФСБ и от Nitrokey последовательно (сначала вставляем один, потом второй и только после этого проходим аутентификацию), чтобы уменьшить вероятность влияния той или иной спецслужбы в отдельности без общего сговора.
sanyo, общая схема аутентификации обычно выглядит так:
1. Сервер сохраняет открытый ключ проверки подписи.
2. Сервер генерирует случайность и отправляет ее на подпись в Рутокен ЭЦП 2.0.
3. Рутокен ЭЦП 2.0 подписывает случайность с использованием закрытого ключа.
4. Сервер проверят подпись с использованием случайности и сохраненного открытого ключа.
Подмешивать дополнительные данные нет необходимости.
У меня нет информации о наличии уязвимостей\закладок в ARM Cortex A7. Более того, рассматривать аппаратные угрозы в этой схеме не имеет смысла. Если кто-то может запустить свой софт на вашем одноплатном компьютере он просто будет атаковать схему проверки и\или будет сам коммутировать. Это куда проще, чем искать уязвимости на аппаратном уровне. Это же касается и атак на PS2\HDD\SD.
Любая система, в которой Вы хотите защититься от аппаратных закладок будет очень дорогая. Дешевле будет сделать круглосуточный караул людей с автоматами рядом с Вашим блоком.
Если я правильно понял по работе с парами ассиметричных ключей например в PGP, то:
Подписать можно закрытым неизвлекаемым ключом, проверить подпись можно открытым извлекаемым ключом.
Зашифровать можно открытым извлекаемым ключом, дешифровать можно неизвлекаемым закрытым ключом.
Если я правильно понял схему которую вы предлагаете, то изложив ее своими словами, она выглядит так:
Микрокомпьютер хранит у себя аутентичный открытый ключ(парный для аутентичного закрытого внутри аутентичного токена).
Этим открытым ключом микрокомпьютер может проверять подпись, созданную закрытым ключом внутри криптотокена.
При попытке снятия с охраны предъявляется некий криптотокен, чью аутентичность мы пытаемся проверить путем проверки аутентичности закрытого ключа.
1) Микрокомпьютер генерирует случайное сообщение и отправляет его на подпись в предъявленный криптотокен.
2) Результирующее подписанное сообщение из предъявленного криптотокена проверяется микрокомпьютером на предмет подлинности подписи ранее сохраненным аутентичным открытым ключом.
Есть ли разница с точки зрения безопасности между использованием шифрования/расшифрования и подписания/проверки_подписи для верификации на микрокомпьютере экземпляра криптотокена и его неизвлекаемого ключа этого токена?
sanyo, с точки зрения безопасности практической разницы между шифрованием и подписанием нет. И в том и в другом случае будут использоваться стойкие криптографические алгоритмы.
У меня нет информации о наличии уязвимостей\закладок в ARM Cortex A7. Более того, рассматривать аппаратные угрозы в этой схеме не имеет смысла. Если кто-то может запустить свой софт на вашем одноплатном компьютере он просто будет атаковать схему проверки и\или будет сам коммутировать. Это куда проще, чем искать уязвимости на аппаратном уровне. Это же касается и атак на PS2\HDD\SD.
А как можно запустить свой софт на микрокомпьютере, отключенном от интернет, без беспроводных интерфейсов, если он находится в металлическом боксе, охраняемом сертифицированной сигнализацией, если только в этом микрокомпьютере нет беспроводных закладок или возможности телепортироваться или полтергейстовать прямо внутри металлического бокса откуда то извне охраняемого помещения?
Любая система, в которой Вы хотите защититься от аппаратных закладок будет очень дорогая. Дешевле будет сделать круглосуточный караул людей с автоматами рядом с Вашим блоком.
Сомнительно, что в MIPS процессорах роутеров, есть закладки, рассчитанные на управление универсальной осью типа полноценной Linux Devuan? Интересно появление прошивки LibreCMC без блобов была неожиданна для тех, кто разрешил их выпуск на рынок или запланированно ими?
Вот если взять такой роутер с USB разъемом на базе MIPS процессора в качестве управляющего микрокомпьютера, загрузиться в LibreCMC, чрутнуться в Devuan 9/10, то какая вероятность наличия закладок в таком железе, которые могли бы повредить безопасности вышеописанной схемы аутентификации охранной сигнализации?
sanyo, если вы не доверяете ARM Cortex A7, то непонятно, почему доверяете LibreCMC или Devuan.
Оценка вероятности угрозы это не то, что можно сделать быстро. Если этот вопрос Вас интересует - Вы можете заказать аудит у любой из компаний, предоставляющей такие услуги.
sanyo, если вы не доверяете ARM Cortex A7, то непонятно, почему доверяете LibreCMC или Devuan.
Оценка вероятности угрозы это не то, что можно сделать быстро. Если этот вопрос Вас интересует - Вы можете заказать аудит у любой из компаний, предоставляющей такие услуги.
Я обычное физическое лицо, подвергаемое воздействию ганстолкинга.
У меня нет средств на аудит и разработку серьезных средств защиты.
Если обычные охранные сигнализации, сертифицированные по ГОСТу не выполняют своего предназначения, то почему физлицо должно что-то изобретать самостоятельно?
У меня демонстративно сперли кабель программирования из охраняемого сигнализацией помещения и даже отдельно охраняемого шкафа внутри помещения. Что мне делать ? Вечером в выходные кабели были положены в шкаф, а уже вечером в понедельник кабели испарились из шкафа вместе с пластиковой банкой, в которой они лежали. В мое отсутствие постановки/снятия/тревоги не было зафиксировано ни на пульте, ни на моем сотике, когда я вернулся вечером сигнализация НЕ была в тревожном состоянии, но и банки с кабелями уже тоже не было.
sanyo, если вы не доверяете ARM Cortex A7, то непонятно, почему доверяете LibreCMC или Devuan.
А чему мне остается доверять? Devuan и LibreCMC по крайне мере полностью открытые, если не ставить из репозиторий с блобами.
Здравствуйте, sanyo.
Вот скажите, как такое может быть, что:
Вопросы слишком оригинальные для этого форума, но оживить тему, боюсь, не помогут )
Похоже, что может возникнуть некоторая путаница в отношении интеграции между криптографическими смарт-картами и конкретными протоколами, используемыми в описываемой вами системе, особенно с интерфейсом Touch Memory. Проблема заключается в том, что криптографические смарт-карты и Touch Memory предназначены для разных целей — одни для обеспечения высокого уровня безопасности посредством шифрования, а другие как более простой протокол для доступа к устройству.
Ваша идея прикрепить криптографический считыватель к металлическому корпусу для дополнительной безопасности и защиты интерфейса от внешнего вмешательства обоснована, но могут возникнуть трудности с достижением необходимого вам уровня совместимости с конкретными упомянутыми продуктами.
Хотя многоканальное программное обеспечение, HRIS и программное обеспечение для цепочки поставок функционируют для оптимизации и защиты процессов в различных отраслях, в этом случае реальная проблема заключается в обеспечении совместимости компонентов системы с надежной криптографией, которую вы собираетесь использовать. Возможно, стоит обратиться напрямую к производителям карт и считывателей, чтобы узнать, предлагают ли они поддержку преобразования или сопряжения с протоколами Touch Memory.
Короче говоря, подробная консультация с поставщиком оборудования должна прояснить путаницу и помочь подтвердить, может ли ваше видение криптографической безопасности быть полностью реализовано.
Чтобы отправить ответ, нужно авторизоваться или зарегистрироваться
Форум Рутокен → Техническая поддержка пользователей → Настоящая криптографическая карта для аутентификации в СКУД (не RFID)