12 слабых мест в СКУД

При этом черный список может занимать на картах пользователей строго ограниченный объем памяти. Не скажу точный объем - но это точно меньше 100 байт (это в случае, если все 65 000 карт туда включены).

в 100 байт вы уложите коды 65000 карт?

Вы не ошиблись в написании?

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

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

вот еще раз уточню: вы утвеждаете, что в блок длиной 100 байт вы записываете стоп-лист о 65000 (Шестидесяти пяти тысяч) карт?

Так, всем привет, я снова в канале и готов к дискуссиям. Поехали!

2 Avk.

Вы ваш чёрный список список укладываете в 8 байт, я правильно понял? В виде диапазона?

Мне кажется, ваша системочка (не продукт, а именно архитектура) действительно близка к "билетным", только не метрошным, а, скорее, наземного транспорта - в части офф-лайн ТД. Ну очень похоже местами на работу билетика "90 минут" :-).

Что вы подразумеваете под "верификацией" применительно к вашей архитектуре? Т.е., какую часть обмена данными?

И вот этот вот "специальный контроллер" (типа узловой) - он на какой дальности может поддерживать радиоточки? ZigBee в любой реализации ведь очень "короткий" - единицы метров, десяток - уже с натягом; и медленный до жути - скорость никакая, для избыточности просто нет запаса. И как? Если объект протяжённый - так этих контроллеров пачками придётся ставить.

Я склонен соглашаться с Андреем применительно к общей схеме взаимодействия компонентов СКУД. Считается (это ведь и в ГОСТе есть), что все они едины. Так что система, как целокупность элементов, действительно не зависит от... э-э-э... подробностей устройства этих отдельных элементов, нет?

Бухарову.

Насчёт обрыва связи - мне сложно представить, чтобы центральный контроллер или сервер БД не поднял бы тревогу, переполошив мирно спящую охрану :-))), при потере связи с любым подведомственным устройством. Если же не поднимет - то, верно, не всё в порядке в Датском королевстве СКУДов.

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

Тем не менее, клонирование в корпоративных СКУД начинает раздражать. Биометрика тоже, к слову сказать, копируется при желании и умении довольно-таки просто (пальцы, а радужка - ну, не те денежки). Да и не особо пригодна к массовому допуску, тем более, с посетителями. Так что защита от "атаки клонов" акуальна.

Только подход разный у меня и у Avk'а. Он на криптообмен смотрит, уповая на эшелонирование, а я считаю полезным бойца на входе заставить шевелиться, сверяя рожи с фотами - типа оно дешевле обойдётся, всё равно ж ему там торчать. А вглубь и так сойдёт.

вы утвеждаете, что в блок длиной 100 байт вы записываете стоп-лист о 65000 (Шестидесяти пяти тысяч) карт?

Вы ваш чёрный список список укладываете в 8 байт, я правильно понял? В виде диапазона?

Вы же знаете - я не разработчик, а всего лишь "двигатель товара" :-)

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

Что вы подразумеваете под "верификацией" применительно к вашей архитектуре? Т.е., какую часть обмена данными?

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

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

"специальный контроллер" (типа узловой) - он на какой дальности может поддерживать радиоточки?

Если же говорить о радио-инфраструктуре, которая поддерживает работу беспроводных онлайн точек доступа - то она состоит из шлюзов и вспомогательных узлов (или повторителей - в разной реализации). Все эти устройства обладают схожими параметрами по обслуживанию RF устройств - до 16 устройств, с расстояниями порядка 15-30 метров.

Вообще, в далеком 2010 году я делал статью на эту тему - если интересно, взгляните http://daily.sec.ru/2010/06/18/SKUD-bez-provodov-idei-primeri-realizatsii-perspektivi.html Там как раз про скороть и другие параметры обмена данными по радио.

Считается (это ведь и в ГОСТе есть), что все они едины. Так что система, как целокупность элементов, действительно не зависит от... э-э-э... подробностей устройства этих отдельных элементов, нет?

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

Касательно "целокупности" - это почему она не должна зависеть от отдельных элементов? То, что нас к этому приучили идентификационные СКУД (где я могу к контроллеру одного производителя прикрутить считыватель от другого, карты от третьего, датчики от четвертого и т.д...) вовсе не значит, что это аксиома.

По простой логике: как только я вместо "индентификатора" начинаю мыслить понятиями "даннные" - сразу возникает естественное требование обеспечить защиту этих данных. Причем на абсолютно всех участках: карта-считыватель, считыватель - контроллер, контроллер - БД СКУД... Все участки надо защищать, т.е. криптография. Чтобы использовать чужие считыватели - надо другому производителю сказать свои коды шифрования. А секрет, известный двум.... Ну Вы понимаете.

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

Эх, ну не умею я кратенько....

Avk.

Да и разглашать какие-то тонкие детали технолгии я не уполномочен.

Для тонких деталей есть патенты.

Сравнивается принадлежность к одному объекту, наличие на карте разрешения доступа к данному контроллеру (точке доступа), с учетом временных таблиц и календарных дат

А вот этого уже многовато для 112 байт imho.

Верификационная СКУД в этот ГОСТ в принципе не помещается, он (ГОСТ) не предусматривает такой архитектуры системы.

А ГОСТ вообще не архитектуры описывает, а принцип взаимодействия. Обычно за идентификатор принимается серийный номер карты. В Вашем случае идентификатором является некоторый массив данных на карте. Карта - в любом случае - является вещественным носителем всего лишь.

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

Ещё и за неё заплати, угу.

с расстояниями порядка 15-30 метров.

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

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

Ах, вот оно, собака-то где порылась! Вы от совместимости элементов отказались? Толково! Типа, связался клиент с вашим барахлом оборудованием - и всё, не соскочит.

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

Аф-фигеть! Типа по стандартным интерфейсам программную крипту прогнать религия не позволит? А-а-а, карта ж у вас тупенькая вовсе, нетути на ней проца, да и мозги в одну извилину, ай-яй-яй. Да, тяжко.

Для тонких деталей есть патенты.

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

А вот этого уже многовато для 112 байт imho.

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

В Вашем случае идентификатором является некоторый массив данных на карте.

Вообще-то сам термин "идентификатор" подразумевает его неизменность и уникальность (хотя бы в теории). У нас же данные на карте меняются - причем постоянно, причем изменять эти данные может любая точка доступа независимо от её типа. Так что, извините - это НЕ идентификатор. И в ГОСТе нет принципа взаимодействия, подразумевающего перенос данных (динамически меняющихся) на карте. Там даже такого типа систем нет - поскольку описанная мной система не подходит ни под определение сетевой - ни автономной, ни универсальной....

Ещё и за неё заплати, угу.

не хотите - не надо. Кто ж заставит? прокидывайте километры "бесплатных" проводов, платите "бесплатную" зарплату монтажникам... Это ж все принято отдавать даром!

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

У Вас, я так понимаю, богатый личный опыт работы с ZigBee на реальных объектах? Сколько объектов поставили, если не секрет?

Мы поставили таких объектов уже несколько десятков. Не скажу, что все в розово - фиолетовых тонах, у радио тоже своя "сторона медали" есть, чего тут скрывать. Только, во-первых, заявленые цифры ОЧЕНЬ близки к реальным (чтобы Вы потом меня не пинали: для основного - на сегодня - типа устройств с радиомодулем этот параметр "до 15 метров", для нового поколения, которое только-только "начало поступать на полки" - до 30 метров).

И потом - из статьи, надеюсь, Вы увидели, что при описанной архитектуре наличие онлайна есть ДОПОЛНЕНИЕ основного функционала, т.е. потеря связи не приведет к неработоспособности точки доступа.

Вы от совместимости элементов отказались? Толково! Типа, связался клиент с вашим барахлом оборудованием - и всё, не соскочит.

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

А не приходилось выслушивать клиента, котрому для выяснения причин косяка в системе пришлось ЗАСТАВИТЬ собраться за одним столом представителей 3-4-5 компаний, которые поставляют софт - контроллеры - считыватели - блоки питания - и т.д. на СКУД. И при возникновении проблемы автоматически "переводят стрелки" друг на друга. И пока клиент пару кругов по этим "стрелкам" не пройдет и не позеленеет от злости - разбирать проблему просто не начинают?

Да, у нас такой лафы нет. Стрелки, знаете ли, не на кого переводить.

Я Вам вообще страшную вещь скажу: для некоторых типов карт, с которыми мы работаем (тот же MiFare Classic / PLUS или Desfire) даже карты заказчики ВЫНУЖДЕНЫ покупать только у нас! Так как сектора памяти на карте тоже закрывать шифрованием надо - и делается в основном на заводе... Вот ужас-то!

Аф-фигеть! Типа по стандартным интерфейсам программную крипту прогнать религия не позволит? А-а-а, карта ж у вас тупенькая вовсе, нетути на ней проца, да и мозги в одну извилину, ай-яй-яй. Да, тяжко.

Согласен - АФ-фигеть! Это ж каким путем Вы к такому шикарному выводу шли-то??? Приз по женской логике все-таки Ваш!

Стандартные протоколы шифрования (AES, 3DES) подразумевают наличие ключей шифрования как на носителе (карте) - так и в устройстве (считывателе и т.п.). Чтобы они туда попали - нужна специальная процедура (поговрите со специалистами по криптографии, они куда лучше моего объяснят технологии передачи и хранения ключей в упомянутых протоколах шифрования). И технология, кстати, подразумевает НАЛИЧИЕ на карте (той самой - "тупенькой") аппаратного криптопроцессора... И передаваемая по СТАНДАРТНЫМ интерфейсам (RS485 или Ethernet) инфа криптуется все по тем же открытым протоколам.

Коллеги - в очередной раз мне приходится несколько страниц кряду заниматься описанием и защитой конкретной системы или пусть даже архитектуры - что имеет достаточно слабое отношение к теме дискуссии. Вам так не кажется?

Все тут понятно. Мы начали с вопроса: можно ли обмануть систему с суперзащищенной картой. Я показал: можно. Вот с ходу еще несколько способов:

1. купить у владельца. Договориться, что он через неделю заявит о пропаже.
2. найти админа, дать денег, и он эмитирует Вам нужное количество карт.
3. влезть прямо в провода (между контроллером и турникетом каким)... тоже не бог весть какая сложная процедура.

Вывод в любом случае один: преодолеть СКУД при необходимости не сложно.

Далее эту тему обсуждать нет смысла.

А вот, уважаемый Avk, покажите, пожалуйста стомость этой системы для такой конфигурации:

1. считывателей-20 шт, для управления - сухой контакт (Т.е. замки - турникеты - шлагбаумы в расчет не включаем)
2. карт 1500 шт.
3. Набор ПО для подготовки и управления картами, ведением журнала событиями и отчетами.

Сколько денег придется выложить?