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

Всем привет, коллеги - после небольшого отсутствия я снова в строю.

Радует, что в нашем полку прибыло - но после воскресного взрыва как-то все затихло. Неужто и вправду все - тема диспута исчерпана?

To Troll:

Нет, "близки" - это все-таки как минимум не меньше 10-12 метров. Конечно не в случае, когда это металлический ящик (против физики не попрешь). Вместо калькулятора дальности мы предпочитаем использовать специальный RF Tester - чтобы на месте проверить реальные расстояния.

Одного специалиста СКУД не нашлось в этой тьмутаракани, вместо кучку манагеров-двигателей товара?

Вот именно с этим у нас в стране реальная проблема! И похоже не только по СКУД-у, а вообще по любым сложным системам найти спеца (даже в Москве) совсем непросто... Увы...

Самим в "специальный" контроллер зашить нужную алгоритмику и прописывать ключи на смарт-картах религия запрещает?

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

"Я Вам не скажу за всю Одессу", как говорят в классике (еще раз признаюсь - ну не спец я по тонким деталям алгоритмов криптования...) - и тем не менее...

1. В считыватель ключи шифрования ДОЛЖНЫ попасть до того, как к нему будет предъявлена карта с этими же ключами. Это просто нелогично было бы делать с самой карты - типа предъявил карту, она сама считывателю отдала ключи шифрования и тут же еще и данные, этими ключами зашифрованные... Согласны? Именно поэтому я и упомянул "процедуру". Мне лично известно 3 возможности сделать это (со считывателем): на заводе, специальным программатором или специальной картой (полученной с того же завода) уже на объекте.

2. Считыватель - если только это не тупая антенна в пластике, ДОЛЖЕН сам "доставать данные с карты" без прямого участия контроллера. Потому как никакой "криптосуммы" считыватель с карты не считает. Ничего, кроме нулевого сектора (где есть открытый UID карты и данные для "начала разговора с картой" типа таблицы размещения приложений) Вы не получите, пока не предъявите карте свои "права доступа" на определенные сектора (как в MiFare) или приложение (как в Desfire). И уже получив разрешения на определенные сектора, считыватель начинает транслировать их в контроллер.

Iron Logic и Parsec, если почитаете описание работы их считывателей в защищенном режиме, раблотают точно так же (или почти так же).

И зачем вам DES? вы ж ГОСТы любите? - Ну и возьмите 28147-89, там всё подробненько.

Да я бы с удовольствием... Только вот NXP (которые MiFare и Desfire карты делают) и иже с ними как-то не очень понимают термин "ГОСТ", знаете ли... А в России до производства сопоставимого продукта (карт с крипитозащитой) как-то еще никто не дорос, увы.

Avk'у.

Вместо калькулятора дальности мы предпочитаем использовать специальный RF Tester

Хорошее решение.

вообще по любым сложным системам найти спеца (даже в Москве) совсем непросто... Увы...

Ну, не знаю... по-моему, вопрос только в деньгах, мне так кажется. Может, ещё в странной "любви" к манагерству и традиционному, ещё с советских времён, недоверию к "спецам" - как к "социально чуждому элементу" :-(.

Религия - нет (она вообще как-то к криптографии исторически не очень хорошо относится...)

А вот это вы зря - как раз довольно-таки серьёзный вклад в развитие криптографии и криптоанализа внесли именно религии с их вечными тайнами и учёными, изыскующими раскрытия этих тайн. Вклад, скажем, христиаства в криптографию неоспорим. Да и мусульманство отличилось.

В считыватель ключи шифрования ДОЛЖНЫ попасть до того, как к нему будет предъявлена карта с этими же ключами.

Так, вот тут давайте мы определимся с терминами; 1) "считыватель - это устройство преобразования кода носителя идентификационного признака в электрический (или иной) сигнал, удобный для последующей обработки контроллером доступа"; 2) "Контроллер доступа - устройство, выполняющее идентификацию или иную процедуру сравнения кода идентификационного признака со списком допущенных кодов для принятия решения на доступ".

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

Повторяю вопрос - нафига ему ключи?

Считыватель - если только это не тупая антенна в пластике, ДОЛЖЕН сам "доставать данные с карты" без прямого участия контроллера.

Зачем? Что мешает контроллеру принять участие?

Потому как никакой "криптосуммы" считыватель с карты не считает

Это ещё почему? Чем зашифрованное поле памяти отличается от незашифрованного? С точки зрения чтения-записи?

Ничего, кроме нулевого сектора (где есть открытый UID карты и данные для "начала разговора с картой" типа таблицы размещения приложений)

Для начала "разговора" с картой достаточно импульса presence на шине.

Вы не получите, пока не предъявите карте свои "права доступа" на определенные сектора (как в MiFare) или приложение (как в Desfire)

Ещё как получу, даже и спрашивать не буду. Другое дело - не смогу расшифровать полученное и извлечь из него пользу, не зная ключа. Но это задача для контроллера.

Iron Logic и Parsec, если почитаете описание работы их считывателей

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

Нет, не согласен - это актуально только в том случае, если мы говорим об идентификационной системе, задача считывателя в которой как раз и есть описанное Вами "преобразование идентификационного кода" и передача его строго в одну сторону по принципу "отдал - забыл"

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

Повторяю вопрос - нафига ему ключи?

Без них никакого обмена данных не состоится.

Что мешает контроллеру принять участие?

Много чего. Например - отсутствие в контроллере криптопроцессора, совместного с таковым на карте (криптование данных между контроллером и считывателем - а также между контроллером и БД делает другой криптопроцессор). Помимо прочего эта схема позволяет к одному и тому же контроллеру подключать РАЗНЫЕ считыватели, заточенные под разные типы криптокарт

Чем зашифрованное поле памяти отличается от незашифрованного? С точки зрения чтения-записи?

Не совсем понял термин "поле" - давайте рассмотрим на примере MiFare Classic 1K. На карте 16 секторов, Нулевой - сектор производителя. Там "забетонирован" UID карты ("серийник", в простонародье) и записан каталог приложений MIFARE Application Directory (MAD). И нулевой сектор не совсем корректно называть неперезаписываемым, кстати...

Сектора с 1-го по 15 доступны под хранение пользовательских данных. На каждый сектор установлена СВОЯ пара ключей А и В. Ключ А дает доступ только на чтение, ключ В - на запись (при наличии кода А).

UID позволяет считывателю понять, с какой картой он сейчас разговаривает, и говорит ему, на каком "языке" с ней говорть (считыватель может одновременно работать с несколькими типами карт, поэтому без умения понимать тип карты по UID он с ней просто не сможет работать - это к ранее обсуждаемому вопросу MiFare с UID длинной 4 и 7 байт http://www.mifare.net/ru/technology/4-7byte-uid/).

А MAD - говорит, в какие сектора идти за требуемым приложением

Определив тип карты и местонахождение "родного" приложения, считыватель предъявляет свои права на чтение из этих секторов (на основе ключа А - но сам ключ в пространство не передается, естественно) и начинает передачу данных из них в контроллер.

Получив задание записать что-то назад на карту, в дело вступает ключ В и считыватель производит запись.

Для начала "разговора" с картой достаточно импульса presence на шине.

Простите - но нет, не достаточно. Если не считать "разговором" получение UID, который предназначался разработчиком вовсе не для ИДЕНТИФИКАЦИИ по карте где бы то ни было, а только для указания считывателю типа карты и инструкции по дальнейшему порядку ведения диалога.

Ещё как получу, даже и спрашивать не буду. Другое дело - не смогу расшифровать полученное и извлечь из него пользу, не зная ключа. Но это задача для контроллера.

И снова, простите - но НЕТ. См. выше.

То есть можно построить обмен описанным способом.

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

Avk.

Нет, не согласен

Дайте ваши определения для считывателя и для контроллера.

порядок работы с картой мало зависит от производителя считывателей - он жестко описан производителем карт. Шаг влево вправо - расстрел.

Вот здесь http://idcard.com.ua/specification/MF3ICDX21_41_81_SDS.pdf#G1666820 - подробная спецификация на Desfire Ev1. Из которой следует, в частности, возможность произвольной записи/чтения в nvram, как с ключами, так и без них, как с защитой считывания, так и без таковой. Конкретный протокол обмена программируется разработчиком приложения (которых может быть до 28 одновремено на карте).

В таблицах 6-10 как раз указаны команды для обеспечения обмена данными в любом возможном режиме.

Мне кажется, вы путаете частный случай решения для конкретного продукта с обобщёнными правилами организации шифробмена. Впрочем, это не существенно :-), в видах данной дискуссии.

To Troll - простите. снова несколько дней не было возможности продолжить дискуссию.

Дайте ваши определения для считывателя и для контроллера.

Определения по ГОСТ-у Вы уже ранее давали: "Считыватель - Устройство, предназначенное для считывания (ввода) идентификационных признаков."

Меня в этом определении не устраивает тот факт, что текущая версия ГОСТ не подразумевает двустороннего обмена данными в случае применения соотвествующего типа карт (понятно, что такой обмен невозможен в случае биометрии или пассивных меток типа EmMarine).

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

Естественно - не претендую на абсолютную корректность именно такого определения, но факт остается фактом - современные определения ГОСТ-а отстали от действительности.

Описание контроллера все в том же ГОСТ более чем общее: "контроллер доступа (КД), прибор приемно-контрольный доступа (ППКД): Аппаратное устройство в составе средств управления СКУД." Ну вот пусть таким и остается, пожалуй...

Мне кажется, вы путаете частный случай решения для конкретного продукта с обобщёнными правилами организации шифробмена.

Указанный Вами пример с Desfire только подтверждает все то, о чем я говрил ранее (мне, кстати, этот тип носителя нравится куда больше - возможностей он предоставляет на порядок поболе всеми любимого МайФера...).

Только когда Вы говорите о

возможность произвольной записи/чтения в nvram, как с ключами, так и без них, как с защитой считывания, так и без таковой

то скорее ошибаетесь как раз Вы.

В указанном Вами документе сказано: Prior to data transmission a mutual three pass authentication can be done between MIFARE DESFire EV1 and PCD depending on the configuration employing either 56-bit DES (single DES, DES), 112-bit 3DES (triple DES, 2K3DES), 168-bit 3DES (3 key triple DES, 3K3DES) or AES. During the authentication the level of security of all further commands during the session is set.

т.е. прежде чем начнется какая-то передача данных, карта и считыватель должны пройти процедуру взаимной аутентификации. Не совсем понимаю, как Вы представляете себе такую процедуру без ключей? Даже если это транспортные ключи (известные всем) - они все равно присутствуют.

И только после этого и начинается собственно передача данных одного из 3-х возможных типов: Plain data transfer (передача простого текста), Plain data transfer with cryptographic checksum (MAC) (передача текста с криптографической контрольной суммой) и собственно Encrypted data transfer (т.е. передача зашифрованных данных).

Действительно, тип передачи определяется приложением (его разработчиками) - но кто с этим спорил? Я - точно нет.

Впрочем, это не существенно :-), в видах данной дискуссии.

Вот тут согласен - копание в токностях той или иной КОНКРЕТНОЙ технологии реализации не поможет в нашей дискуссии а скорее внесет сумятицу. Я, возможно, где-то сам виноват, что мы слишком глубоко влезли в эту тему - но по моим сугубо личным ощущениям слишком мало народу даже из среды специалистов реально понимают описанные механизмы и потому крайне редко их применяют или ищут решения, их использующие.

Ранее Вы сами сделали два замечательных высказывания, с которыми я полностью согласен:

Надеюсь, наше обсуждение попадает как раз под это обсуждение? Мне кажется - да.

и еще одно:

Выход из криворукости известен - людей надо УЧИТЬ работать.

И тут согласен целиком и полностью - тем более что Вы ведь именно таким обучением себе на жизнь и зарабатываете? И в дискуссию с Вами я ввязался с таким энтузиазмом как раз потому, что через Вас надеюсь донести свою позицию до других специалистов. Но только в том случае, что вначале мне удастся убедить в чем-то Вас лично.

Avk.

Определения по ГОСТ-у Вы уже ранее давали

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

ГОСТ немножко устарел, да, но это не страшно - объектовые системы ж не по ГОСТу делаются, а по проекту, точно? А проект тоже не обязан ГОСТу соответствовать. ГОСТ вообще, по сути дела, просто для сведения существует.

Указанный Вами пример с Desfire только подтверждает все то, о чем я говрил ранее (мне, кстати, этот тип носителя нравится куда больше - возможностей он предоставляет на порядок поболе всеми любимого МайФера...)

Вот тут у меня когнитивный диссонанс :-): Desfire - это же тоже Mifare?

В указанном Вами документе сказано: Prior to data transmission a mutual three pass authentication can be done

Верно, can be; но не must be. Чуть далее там "Plain data transfer (only possible within the ackwards-compatible mode to MF3ICD40" - хотя и не рекомендуемый режим, но можно открытым текстом общаться. А и в случае 3DES никто, в сущности, не мешает пустой ключ задать.

карта и считыватель должны пройти процедуру взаимной аутентификации.

Не должны пройти, а могут пройти; а могут и не проходить, дело разработчика приложения. Кроме всего, Desfire предыдущей генерации уже был успешно атакован, атака EV1 дело только времени.

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

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

Ну, это вы зря, специалисты на то и специалисты, чтобы все, как минимум, базовые процедуры знать чётко. Просто вопрос построения обычно упирается в смету, и не до изысков.

вначале мне удастся убедить в чем-то Вас лично.

А смотря в чём. Об актуальности борьбы с клонированием я и так в курсе. А вот насчёт поиска дорогих решений при наличии более дешёвых вы меня едва ли убедите: я бы, может, и не против был, а вот мои клиенты - против! Хотят дёшево - и всё.

И в том, что в СКУД можно полностью отказаться от работников-людей. т.е., от вахтёров/контролёров, тоже не убедите, потому что видел я много ситуаций, когда надо было обойти объектовые правила доступа. Контролёру (человеку) это сделать реально, а контроллеру (прибору) - мимо. Ну и история СКУД, как она есть, СИЛЬНО старше любой техники. Т.е., СКУД существовали ещё во времена борьбы с пещерным медведем. Эксплуатируя в те далёкие времена, кстати сказать, самые передовые, биометрические технологии ;-). А контроллерам ещё и полувека не далось. Ткскть, история проповедует нам :-))).

А разговор наш с вами с пользой для ума, да.

день добрый, Troll

Вот, к примеру, считыватель чип-карты для банкомата - у него вполне двусторонний обмен, хотя речь не об аутентификации

там принцип ТОЧНО такой же: сначала аутентификация (взаимная) считывателя и карты - и только потом обмен.

ГОСТ немножко устарел, да, но это не страшно - объектовые системы ж не по ГОСТу делаются, а по проекту, точно?

Все мои ссылки на ГОСТ только потому - что где как не там мы с Вами должны искать определения терминов?

Вот тут у меня когнитивный диссонанс :-): Desfire - это же тоже Mifare?

Диссонанс не только у Вас :-)

В документе, на который Вы прошлый раз ссылались, есть веселая фраза:

"The main characteristics of this device are denoted by its name “DESFire”: DES indicates the high level of security using a 3DES or AES hardware cryptographic engine for enciphering transmission data and Fire indicates its outstanding position as a fast, innovative, reliable and secure IC"....

Типа "в имени моем - вся моя крутизна"... DES - потому что высший уровень безопасности основанный на 3DES и AES, а Fire - потому что "огонь какая крутая штука, вах :-) ".

Это я к чему.... Существует НЕСКОЛЬКО принципиально разных чипов от отного и того же производителя - NXP. И носят они следующие имена:

1. Mifare Classic (он-же "просто Mifare") с делением памяти на фиксированные сектора и проприетарным криптоаглоритмом CRYPTO-1, благополучно вскрытым некоторое время назад

2. Mifare PLUS - который может начать работать на CRYPTO-1 но потом программно переключиться на AES ("наш ответ Чемберлену" - т.е. ответ на вскрытие CRYPTO-1).

3. MiFare DESFire - со свободным делением памяти карты на приложения (а не сектора) и криптованием по 3DES и AES

А еще есть Mifare Mini, Mifare Ultralight, MiFare Ultralight C (Crypto)....

Кроме всего, Desfire предыдущей генерации уже был успешно атакован, атака EV1 дело только времени.

Безусловно - в мире нет ничего вечного.

именно поэтому я и пытаюсь все время указать на идею, что единственная технология защиты от уязвимости карт - использование карты все лишь как носителя данных. Эти данные должны быть независимы от носителя и защищены технологиями, напрямую с картой не связанными (программное шифрование). Возникла проблема уязвимости карт - у Вас есть "вторая линия обороны" и соответственно время на естественный (т.е. постепенный) переход на новый, еще не вскрытый носитель. Изобретение это не мое - не подумайте страшного - и многие производители (в мире) УЖЕ так и поступают.

имеет смысл риски клонирования и "ложного прохода" посчитать, сравнив с ценой аутентификации. Хотя, опять-таки, можно ж вместо неё верификацию pin-кодом задать, что вообще копейки.

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

Ну, это вы зря, специалисты на то и специалисты, чтобы все, как минимум, базовые процедуры знать чётко. Просто вопрос построения обычно упирается в смету, и не до изысков.

Не могу разделить Вашего оптимизма. Только я имел ввиду не "процедуры" - а все таки СОВРЕМЕННОЕ положение дел в данной области (по технике, то есть). Ведь даже у Вас когнитивный диссонанс на предмет MiFare DESFire - а многие и имени такого не слышали... Да и по сметам - Вы думаете мы на луне работаем, и там деньги никто не считает? Вопрос - как считать и как сравнивать. А уж про такой термин, так "стоимость владения" вообще умолчу...

И в том, что в СКУД можно полностью отказаться от работников-людей. т.е., от вахтёров/контролёров, тоже не убедите

Здравствуйте, Avk.

Все мои ссылки на ГОСТ только потому - что где как не там мы с Вами должны искать определения терминов?

Ну, хэ-хэ, стандартов в мире много, кроме ГОСТов, которые зачастую не успевают за прогрессом. Вона, Баканов в соседней ветке, пока её не прибили, не стеснялся в разные там ISO и проч. лазить. И мы можем, если от этого толк будет.

Это я к чему.... Существует НЕСКОЛЬКО принципиально разных чипов от отного и того же производителя - NXP. И носят они следующие имена:

В курсе; всё-таки, все они из семейства Mifare.

единственная технология защиты от уязвимости карт - использование карты все лишь как носителя данных.

Я никак не уловлю, чем использование HID Classic (или EmMarine) отличается от вашей идеи. Там тоже карта - только лишь носитель идентификационного признака, а вовсе не сам признак. Если б вы на модифицируемость признака указывали - другое дело, а так принцип-то не меняется, по большому счёту. Это всё как раз о терминологии, de dicto, ткскть.

время на естественный (т.е. постепенный) переход на новый, еще не вскрытый носитель.

А вот, кстати, вопрос: числовые динамические коды - изобретение не новое, я о таком читал ещё в 70-е, что ли. Но ни одной рыночной системочки доступа с такой фичей не встречал. А почему, собственно? Типа, юзерям тяжко? Ничего, переживут, если так уж именно защита нужна. Может, вы примеры знаете такой системы?

Если бы это было так просто... Ваш же пример с аэропортом - как посчитать стоимость таких рисков?

А в чём проблема? Статистика авиапроисшествий есть, берём нужные разделы, относим к пропускной способности (за год, скажем), затем рассчитывем убытки по категориям происшествий, относим полученный результат к первому, и вот вам расчёт убытка на единицу риска.

Может оказаться - и, зачастую оказывается (в России, а как за бугром, спросить надо у авиаторов), что вахтёр сильно дешевле криптокарт.

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

Не то, чтобы заоблачной, но дорогой: карты х10 + процедуры: гаммирование, формирование и смена ключей (периодически), верификация носителей, синхронизация протоколов - мно-ого работы. И - людей много, которые этим будут заниматься, только вместо вахтёров с 8-ю классами (с 10-ю нынешними) понадобятся бакалавры, а то и магистры. Да и криптографию в России преподают всерьёз ровнёхонько в двух учебных заведениях.

А уж про такой термин, так "стоимость владения" вообще умолчу...

Видите ли, коллега: в моей скромной практике только за время строительства, бывает, меняется 2-4 собственника. Ну, какая же, к чёрту, стоимость владения? Стоимость для кого? Кто там будет владеть (после очередного рейда) через 5 или 10 лет? "Далёко отсюда до Лохоу", как шотландцы говорили. Не до жиру, освоить бы те средства, что есть вот сейчас - если они есть :-(.

Погодите... Это когда я говорил, что СКУД сможет работать без людей?

А вот тут:

вы разве не про то писали?

Максимум - сократить количество персонала

Сокращать можно внутри. А снаружи, т.е. именно на проходных, без вахты никуда. А если с вахтой (и сравнением физий), то вопрос клонирования как бы становится... ну-у... не очень актуален, понимаете ;-)?

Как-то так.

Здравствуйте, Troll - я тут снова был в дороге (собственно, почему "был"... я все еще в процессе :-) Привет с Урала, так сказать... ), так что прошу прощения за несколько дней тишины

стандартов в мире много, кроме ГОСТов, которые зачастую не успевают за прогрессом

А отставание ГОСТ-а от реалий точно не трагедия - но только если в проффесиональном сообществе есть стремление его ликвидировать.

всё-таки, все они из семейства Mifare.

Ну, Вы знаете... Винда от версии 3.11 вплоть до 8-ки (включая серверные версии) тоже вроде как "из семйства Windows"... Так что родственники бывают "очень разные"

Я никак не уловлю, чем использование HID Classic (или EmMarine) отличается от вашей идеи. Там тоже карта - только лишь носитель идентификационного признака, а вовсе не сам признак.

В EmMarine и HID PROX картах их ФИЗИЧЕСКИЕ свойства, заложенные на заводе - изготовителе и есть сам идентификационный признак.

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

Может, вы примеры знаете такой системы?

нет, не встречал - если правильно понимаю, о чем Вы...

А в чём проблема? Статистика авиапроисшествий есть, берём нужные разделы, относим к пропускной способности (за год, скажем), затем рассчитывем убытки по категориям происшествий, относим полученный результат к первому, и вот вам расчёт убытка на единицу риска.

карты х10 + процедуры: гаммирование, формирование и смена ключей (периодически), верификация носителей, синхронизация протоколов - мно-ого работы. И - людей много, которые этим будут заниматься, только вместо вахтёров с 8-ю классами (с 10-ю нынешними) понадобятся бакалавры, а то и магистры. Да и криптографию в России преподают всерьёз ровнёхонько в двух учебных заведениях.

Вот, извините, не понимаю я такого рассчета...

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

Так и со СКУД-ом. Большинство наших клиентов не особенно заморачиваются вниканием в какие-то там "верификации, синхронизации..." Потому как нет в этом практического смысла ДЛЯ ПОЛЬЗОВАТЕЛЯ.

А касательно разработчиков - по мне, двух ВУЗов более чем достатчно. Откуда уверенность, что этим должно заниматься "много народу"?Может пора уже неограниченное количество "самопальных" систем перевести в качество международного уровня ограниченного числа систем Российской разработки?

Даже со стоимостью карт "х10" - Вы что с чем сравнивали?

Ну, какая же, к чёрту, стоимость владения? Стоимость для кого? Кто там будет владеть (после очередного рейда) через 5 или 10 лет?

вы разве не про то писали?

Цитата безусловно, моя - и похоже нас с Вами опять подвела разница в терминологии.

По моему убеждению, задача СКУД - дать в руки КВАЛИФИЦИРОВАННОГО (и потому малочисленного) персонала современный инструмент для эффективного выполнения своих обязанностей. Персонал этот должен не перекладыванием бумажки-пропуска из бюро пропусков в бюро пропусков транзитом через руки посетителей и вахтеров заниматься - а обеспечивать физическую безопасность объекта, отслеживая события как со СКУД, так и других систем (той же CCTV) и применяя оперативные действия.

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

Говоря проще (как в советские времена) - "я против слесарей первого разряда, я за операторов станков с ЧПУ"...

Так сколько же стоит карта?

У меня тут проект похожий есть (защита от клонов нужна). Дык давайте согласуем цены на карты хотя бы... Чтобы рынок не ломать.