Переход с других систем

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

  • Perco 12000
  • Perco 15000
  • Кодос
  • BioSmart
  • Legos
  • Parsec
  • Gate
  • Kantech
  • Барс
  • Болид
  • TempoReale

Во всех этих случаях мы можем перенести сотрудников с их номерами карт. В случае Perco, Кодос, BioSmart, TempoReale — также сохраняются заданные фотографии.

Обращайтесь! Это бесплатно как и многая другая помощь, которую мы можем оказать.

Александр Рыжов, ar@spnx.ru

Рубрика: Без рубрики | Добавить комментарий

О создании дубликатов бесконтактных карт: Mifare

Mifare пока массово не копируются.

Применительно к некоторым членам этого семейства карт копирование существенно технически затруднительно, в том числе существуют карты Mifare, реализующие общепризнанные стойкие криптографические шифры, а полное копирование карты предполагает «взлом» этих шифров (отмечу что к таким не относятся самые распространенные карты Mifare Ultralight и Mifare Classic).

Однако в большинстве случаев не обязательно копировать карту чтобы воспользоваться ей.
Есть несколько способов избежать копирования.

Первый и самый простой из способов базируется на том факте, что большинство считывателей, даже взаимодействуя с потенциально защищенной от копирования картой, не задействуют её шифровальные возможности и проверяют только уникальный идентификационный номер карты, который не является секретом, может быть свободно прочитан с карты и воспроизведен дубликатом карты. Технически создание копии карты в том же физическом формате, что и оригинал, на уровне повторения ее номера делается несложно для профессионалов, но пока недоступно для массового клиента. Это 3500 руб. за оборудование, 500 руб. за «болванку» и немного программирования. У меня нет сомнений, что с ходом времени такая технология будет становится более доступной.

Те же немногие Российские производители, кто делает считыватели, задействующие криптографические возможности карты и этим существенно усложняющие копирование, почти не продают свою продукцию, потому что она никому не нужна, спроса нет в силу разных причин – в этом один из интересных парадоксов рынка.

Смотрите также «Введение».

Александр Рыжов, ar@spnx.ru

Рубрика: Без рубрики | Комментарии (9)

О создании дубликатов бесконтактных карт: EM Marine, HID (125 Кгц)

Такие карты копируются в любом крупном городе рублей за 100. Оборудование, нужное для этой нехитрой операции, стоит 2600 рублей, болванка карты — 40 рублей.

Смотрите также «Введение».

Александр Рыжов, ar@spnx.ru

Рубрика: Без рубрики | Добавить комментарий

О создании дубликатов бесконтактных карт: Введение.

Важные предисловия к теме:

(1) В некоторых случаях даже возможность создания полного дубликата карты не нарушает правил системы и не может поэтому считаться её «взломом». Далее рассматриваем только случаи, когда создание дубликата позволяет нарушить правила. К таким ситуациям относятся, в частности, автоматизированные проходные, когда дубликат позволяет пройти через них.

(2) Как правило, не побоюсь даже сказать «всегда», не надо создавать полный дубликат разрешённой карты, чтобы он «сработал». Т.е. подделке необязательно воспроизводить всё то поведение, которое реализует оригинал.

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

Эти пункты — не только формальные столбики на границе темы. Каждый из них может быть проиллюстрирован интересными технологическими находками, что я попробую со временем сделать.

Александр Рыжов, ar@spnx.ru

Рубрика: Без рубрики | Комментарии (2)

О рангах сети контроллеров СКУД

Поскольку применительно к рангам сети СКУД нет общепризнанных или стандартизированных терминов, то начну с определений для этой заметки:

  • Одноранговая сеть контроллеров СКУД — подход к построению сети контроллеров, при котором все контроллеры играют одинаковую роль в системе и непосредственно управляют исполнительными устройствами (дверьми, турникетами и пр.). Примеры систем: «Parsec», «Perco S-20» и другие.
  • Двухранговая сеть контроллеров СКУД — подход к построению сети контроллеров, при котором часть контроллеров (будем назвать такие контроллеры интерфейсными модулями) занимается управлением исполнительными устройствами, в то время как другие — только управлением интерфейсными модулями. Примеры систем: «Apollo», «Кодос ПРО» и другие.

Еще лет 10 назад невозможно было построить конкурентоспособную по цене СКУД на 10 000 «карточек» придерживаясь «одноранговой» архитектуры. Просто потому что 10 000 раз по нескольку байт — и вот уже набежал объем информации, которую дорого было хранить и обрабатывать на каждом контроллере. Поэтому делались дешевые простые интерфейсные модули и дорогие «мощные» управляющие контроллеры для них. Каждый управляющий контроллер обслуживал несколько модулей.

Сейчас одноранговую СКУД делать можно и нужно. Память и процессор, которые устанавливаются, например, в контроллер «Sphinx E900I», вместе стоят нам 8 долларов. При этом процессор достаточно быстр для задач СКУД, а энергонезависимой памяти там — 4 Мб, что достаточно много для задач, решаемых контроллером СКУД.

Оставшееся место я посвящу борьбе с пережитками, вернее с доводами в защиту двух рангов и смешанной архитектуры.

Что будет при пропадании связи между узлами? Когда в продаваемой системе два ранга, то можно услышать, что при пропадании связи управляющего контроллера с ПК все равно значительная часть функционала сохранится. Но что мешает этому же самому функционалу сохраниться в одноранговой сети? Что мешает вообще всему функционалу сохраняться всегда? Ничего! Если в двухранговой сети отключается управляющий контроллер — значительная часть функций теряется. А в одноранговой сети отключение любого узла не затрагивает другие узлы. Кто-то может упомянуть antipassback и прочую скоординированную деятельность контроллеров, для которой нужен управляющий контроллер. Но нужен ли он? Почему одноранговая сеть не может справляться с этими же самыми задачами, только лучше и надежнее? Она может и она справляется.

Будущее безусловно за децентрализованными одноранговыми системами.

Александр Рыжов, ar@spnx.ru

Рубрика: Без рубрики | Комментарии (6)

О полноценной поддержке турникетов

Поговорим сегодня об одном из самых распространенных преграждающих устройств – турникете.

Кроме внешних отличий их конструкции (триподы, тумбовые, роторные, полноростовые…) есть еще и множество внутренних, не видимых, так сказать, невооруженным глазом :) Одним для открывания подавай короткие импульсы по трем линиям, вторым – удерживай линию на время прохода, у третьих – два датчика прохода, у четвертого – один, пятый не умеет отключать встроенный таймер ожидания прохода и так далее.

Для всех известных турникетов мы постарались учесть все их особенности, но по мере накопления информации выяснилась одна интересная подробность, потом вторая, потом третья… А именно: многие модели турникетов имеют ошибки, либо в конструкции, либо в программе их модулей управления. Многие из этих ошибок возможно как-то учесть на стороне контроллера СКУД, но есть и абсолютно неустранимые.

Первая обнаруженная проблема проявляется на турникетах Пэрко TTR-04.1, TTD-03.1, TTD-03.2 (список может быть неполным).

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

К производителю мы не обращались, устранив её на своей стороне: если после запроса доступа и разблокирования турникета не зарегистрирован проход в течение времени ожидания прохода, то срабатывание датчика прохода в течение следующих 60 секунд регистрируется не как взлом, а как проход по запрошенному идентификатору.

Вторая обнаруженная проблема проявляется на турникетах ОМА с блоком управления OMA-DD.958 (это как минимум турникеты OMA-26.46, OMA-26.56,OMA-26.76, OMA-16.68 и OMA-18.68).

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

Обратились к производителю, получили ответ: «сообщаем, что предварительная проверка турникета ОМА-26.461 на контроллере ОМА-DD.958-1 выявила ложные срабатывания электрозамка при управлении от СКУД. … Рекомендуем Вам установить задержку на снятие сигнала разрешения прохода. «.

Что ж, пришлось устранять проблему самим: для турникетов ОМА снятие сигнала разблокировки турникета происходит теперь не по фронту, а по спаду импульса датчика прохода.

Третья проблема проявляется на турникетах Ростов-Дон (как минимум – все турникеты с модулем управления TNO, с индексом М в конце обозначения модели).

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

Обратились к производителю, т.к. в инструкции такой режим явно предусмотрен, получили ответ: «Фразу «Существует возможность открытия турникета системой СКУД путем одновременного замыкания входных цепей управления турникетом «СКУД1» и «СКУД2» на общий провод(GND) турникета» пункта 4.2 «Паспорта», необходимо удалить. В действительности,  в программе контроллера нет функции одновременного разблокирования турникета «на вход» и «на выход» от СКУДа».

Т.е. проблема в логике модуля управления есть, но устранять ее производитель не собирается. И вот что с этим случаем делать – непонятно. Не рекомендовать к применению турникет вообще? Как минимум придется написать в инструкцию на контроллер кучу накладываемых ограничений при использовании «Ростов-Дона».

Непочатов Алексей, an@spnx.ru. Также опубликовано на блог sec.ru

Рубрика: Без рубрики | Метки: | Комментарии (16)

Что запомнилось с выставки

Ни в коем разе не полная подборка, просто напишу, что вспомню по тематике контроля доступа на выставке MIPS-2009.

1. Равелин показал интеграцию СКУД Gate с 1С:Предприятие 8. Интеграция состоит в дополнении конфигурации 1С объектами, отвечающими за взаимодействие с СКУД Gate, при этом управление списками держателей карт, отчетами и прочим можно выполнять прямо с платформы 1С.
Работа была отмечена наградой за лучшую инновацию, по-моему вполне заслужено.
Кстати, подобная по идеологии интеграция, насколько мне известно, есть еще только лишь у Шэлни.

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

3. СКУД Quest (а также Videonet) теперь принадлежит некой компании Skyros corporation, а вовсе не Пентакон. Показаны новые модели контроллеров, если я все правильно понял по функционалу все тоже самое, но на новой элементной базе.

4. Альфа-прибор показывал новый контроллер АПДА.21. Два считывателя, цена порядка 10 тысяч рублей.

Александр Рыжов, ar@spnx.ru

Рубрика: Без рубрики | 1 комментарий

СКУД «Сфинкс»: Тест на 20 млн проходах

По запросу потенциального заказчика провели тест на скорость получения отчетов при наличии в базе 20 миллионов записей о проходах.

Данные условия не являются критическими для «Сфинкс» в каком-либо смысле, ограничения программы многократно превосходят требования конкретного заказчика.

Как-бы то ни было, тест мы провели и, если кому еще это будет интересно, вот его результаты:

Вкратце результат таков: выборка из базы в 20 миллионов проходов нескольких сотен произвольных событий и построение на их основе аналитического отчета занимает не более 45 секунд.

Александр Рыжов, ar@spnx.ru

Рубрика: Без рубрики | Комментарии (3)

Открытые технологии и безопасность

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

По данной теме уже все придумано до нас :) Концепция обеспечения безопасности посредством засекречивания алгоритмов и протоколов традиционно называется «security by obscurity» («безопасность через сокрытие»).

К шифрам при использовании этого подхода имеет доступ только очень ограниченное число людей. Основные особенности такого подхода:

  1. Используемый шифр не прошел всестороннего независимого анализа. Остается полагаться на компетентность его разработчиков и на то, что они не допустили существенных ошибок. В противоположность этому при разработке открытого шифра весь мир имеет возможность в течение многих лет пытаться найти в нем изъяны.
  2. Используемая реализация (компьютерная программа, аппаратная реализация) не прошла независимого анализа и тестирования. Любая реализация, как правило, содержит ошибки.
  3. Зачастую про используемый закрытый шифр разработчик просто не сообщает достаточно сведений для оценки его стойкости. При этом коммерческий разработчик может быть мотивирован сделать шифр не самым стойким, но зато, например, сократить себестоимость производства устройств, реализующих шифр.
  4. Вышеперечисленные негативные факторы частично компенсируются закрытостью шифра.
  5. Утечка алгоритмов и протоколов в широкий доступ часто приводит к быстрой полной либо частичной компрометации шифра. Один из вариантов утечки — обратный анализ закрытой реализации (кстати, иллюстрация к этой заметке — закрытый шифр карт Mifare Classic, а вот тут можно посмотреть видео как их «ломали»).

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

Александр Рыжов, ar@spnx.ru

Рубрика: Без рубрики | Комментарии (4)

Как оценивать технические решения разных производителей

На сайтах производителей СКУД, в рекламных журналах и на интернет-форумах встречается информация о технических решениях, примененных при создании той или иной системы.

Примеры таких утверждений:

  • В наших контроллерах стоит 32-х битный процессор
  • В наших контроллерах стоят 5 процессоров
  • Процессоры в наших контроллерах работают на частоте 1 ГГц
  • На наших контроллерах исполняется ОС Linux
  • Мы используем сервер БД Oracle
  • Мы используем сервер БД Firebird
  • Мы используем трехуровневую систему предотвращения зависания
  • Мы используем свой уникальный протокол для связи контроллеров с ПК
  • Наша система одноранговая
  • Наша система двухранговая
  • Наш контроллер однопортовый (на одну дверь)
  • Наш контроллер восьмипортовый

Я специально намешал в кучу решения, которые я считаю удачными и неудачными, решения наши и решения других производителей. Зачастую разные производители отстаивают исключающие друг друга точки зрения.

Как понять какие из этих решений удачные, а какие нет? Логично, что нужен критерий удачности решения, сформулированный в самых «конечных» потребительских свойствах продукта. Что конкретно в конечном счете дает то или иное решения для потребителя?

Например, что дает 32-х битный процессор? В чем конкретно «мощность», «скорость», «современность»? Какое конкретное действие с системой происходит быстро? Насколько быстро в тех конкретных условиях, в которых решение будет использоваться? Сколько секунд это займет? Сколько в среднем, сколько максимум?

Имея конкретные метрики, нужно сравнить их с другими решениями. И тут может оказаться что все не так, как казалось по-началу, и что, например, 8-и битный процессор для СКУД ни чем не хуже 32-х битного (или не оказаться).

См. также «О скорости линии связи».

Александр Рыжов, ar@spnx.ru

Рубрика: Без рубрики | Комментарии (40)