Расскажу историю из практики. Я работаю в управляющей компании, и в какой-то момент нам пришлось писать технические условия на СКУД для жилых домов. За сухой фразой «поддержка MIFARE» неожиданно обнаружилась большая инженерно-организационная проблема: как выбрать карты, которые нельзя скопировать у мастера в переходе, и при этом не отдать секретный ключ строительной цепочке.
Ключевой вывод оказался простым: безопасную СКУД делает не название карты, а модель угроз, управление ключами и правильные считыватели. Если система пускает по UID, то хоть напишите на коробке MIFARE десять раз — это всё равно слабая схема. Если же используется SL3, AES-аутентификация, диверсификация ключей и SAM, то уровень атаки становится совсем другим.
Откуда взялась задача
Сценарий был типовой для жилого комплекса: застройщик строит, подрядчики монтируют домофоны и турникеты, управляющая компания потом всё это принимает и обслуживает. В цепочке много людей и организаций. Если кто-то из них получает мастер-ключ от карт, он технически может выпустить сколько угодно «своих» пропусков.
Мы хотели заложить в ТЗ такую схему, при которой:
Требование | Почему это важно |
|---|---|
Карту нельзя дёшево скопировать | Иначе доступ превращается в рынок дубликатов |
UID не является пропуском | UID читается открыто и легко клонируется |
Мастер-ключ не знает подрядчик | Монтажник не должен уметь выпускать карты |
Карты можно перевыпустить | Любая утечка должна иметь сценарий восстановления |
Считыватель реально работает в защищённом режиме | Надпись «MIFARE» в спецификации ничего не гарантирует |
Вот схема, к которой в итоге пришли.
Какие карты вообще встречаются
Если сильно упростить, на рынке СКУД живут два массовых мира.
Частота / семейство | Как обычно работает | Что с безопасностью |
|---|---|---|
125 кГц, EM-Marine и совместимые | Карта отдаёт идентификатор | Номер копируется дешёвым дубликатором |
13,56 МГц, MIFARE Classic | Сектора закрыты CRYPTO1 | Алгоритм давно вскрыт, атаки практические |
13,56 МГц, MIFARE Plus SL1 | Режим совместимости с Classic | Нужен только для миграции, не как целевой режим |
13,56 МГц, MIFARE Plus SL3 | AES-128, защищённая аутентификация | Нормальная база для массового доступа |
13,56 МГц, MIFARE DESFire | Файловая система, AES, более гибкая модель | Дороже, но лучше для чувствительных зон |
Для старого подъезда «чтобы дверь закрывалась» EM-Marine исторически хватало. Для нового жилого комплекса, паркинга, лифтов и закрытых зон — уже нет.
Почему не MIFARE Classic
MIFARE Classic долго был самым популярным вариантом в домофонах. Проблема в том, что он использует CRYPTO1 — закрытый проприетарный алгоритм, который после публичного анализа оказался непригодным как современная защита.
На практике важны три класса атак:
Атака | Идея | Практический смысл |
|---|---|---|
Darkside | Используются слабости генератора случайных чисел карты | Можно восстановить ключ без знания исходных секретов |
Nested | Один известный ключ помогает вскрыть остальные секторы | Дальше карта разбирается быстро |
Sniffing | Перехватывается обмен карта-считыватель | Из авторизации восстанавливаются ключи |
Практический вывод для ТЗ простой: Classic и совместимые клоны нельзя выбирать для новой СКУД, даже если они «усиленные» и выглядят как обновлённый Classic. Закрытый алгоритм, массовость дешёвых заготовок и слабая дисциплина ключей делают такую базу плохим фундаментом.
Почему именно MIFARE Plus SL3
У MIFARE Plus есть идея security levels. Для нас важны два:
Уровень | Назначение | Что это значит для СКУД |
|---|---|---|
SL1 | Совместимость с Classic | Удобно для миграции, но не финальная цель |
SL3 | AES-128 и защищённый обмен | То, что нужно требовать в новом проекте |
В SL3 важны не маркетинговые слова на коробке, а конкретная аутентификация сектора, защищённый обмен и правильная работа считывателя. Если считыватель фактически читает только UID, карта хоть трижды может называться MIFARE — защита в этой точке не участвует.
Честная формулировка такая: правильно настроенная SL3-карта не копируется бытовым дубликатором. Но она всё ещё может быть скомпрометирована плохой архитектурой вокруг неё.
Главные ошибки:
Ошибка | Что происходит |
|---|---|
Пускать по UID | SL3 вообще не участвует, система проверяет открытый номер |
Использовать один общий ключ без диверсификации | Утечка одной точки ломает весь парк карт |
Передать ключ подрядчику | Подрядчик технически может выпускать карты |
Купить считыватель «с MIFARE», но без SL3 | В реальности он читает UID или Classic |
Не иметь сценария ротации | После утечки остаётся только жить с известной уязвимостью |
Как не отдать ключ строителям
Вот главный практический вопрос. Картам и считывателям нужен секрет. Кто его знает?
Плохой вариант: мастер-ключ лежит в Excel, у интегратора, у поставщика карт, у монтажника и ещё у пары людей «на всякий случай». В такой схеме можно сколько угодно говорить про AES, но фактически секрет уже размазан по рынку.
Рабочая схема строится вокруг трёх вещей.
Диверсификация ключей. В карту не зашивается один общий ключ на весь дом. Из мастер-ключа и уникальных данных карты выводится производный ключ. NXP описывает CMAC-based key diversification в AN10922. Смысл в том, что компрометация одной карты не должна превращаться в компрометацию всего объекта.
Разделение ролей. Тот, кто заказывает карты, тот, кто их персонализирует, тот, кто монтирует считыватели, и тот, кто администрирует СКУД, не должны иметь одинаковые права. Это не бюрократия, а нормальная модель угроз.
SAM-модуль. Secure Access Module — это защищённый модуль, который хранит ключи и выполняет криптооперации внутри себя. Подрядчик получает оборудование, которое умеет аутентифицировать карту, но не получает мастер-ключ как строку, файл или настройку в открытом виде.
Что писать в техническом задании
Фраза «поддержка MIFARE» бесполезна. Её напишут почти все, включая считыватели, которые фактически читают только UID.
В ТЗ лучше писать проверяемые требования:
Формулировка в ТЗ | Как проверять при приёмке |
|---|---|
Поддержка MIFARE Plus в SL3 | На тестовой карте закрыть сектор AES-ключом и проверить чтение только после аутентификации |
Запрет доступа по UID как единственному фактору | Карта с клонированным UID не должна открывать дверь |
Поддержка SAM или эквивалентного защищённого хранения ключей | Мастер-ключ не вводится в считыватель открытым текстом |
Поддержка диверсификации ключей | Разные карты получают разные производные ключи |
Сценарий ротации ключей | Поставщик показывает, как перевыпустить карты и обновить считыватели |
Журналирование операций выпуска и доступа | Должно быть понятно, кто выпустил карту и когда она использовалась |
Отдельно стоит просить демонстрацию на реальном оборудовании, а не только паспорт изделия. Именно на этом этапе обычно выясняется, что «MIFARE поддерживается» означает «мы умеем читать номер карты».
Почему это вопрос денег
Безопасность здесь быстро становится экономикой.
Риск | Финансовое последствие |
|---|---|
Жильцы делают дубликаты на стороне | УК теряет доход от выпуска карт |
Посторонние проходят в подъезд или паркинг | Растёт конфликтность, жалобы и репутационный ущерб |
Утёк мастер-ключ | Нужно перевыпускать карты и перенастраивать считыватели |
Куплены дешёвые считыватели без SL3 | Приёмка превращается в спор с подрядчиком |
Поэтому SL3 — это не «безопасники перебдели». Это способ не строить новую систему на заведомо копируемых идентификаторах.
Взгляд из 2026
Если бы я писал ТЗ сегодня, я бы оставил MIFARE Plus EV2 SL3 как разумный массовый вариант для жилых объектов, но добавил бы три уточнения.
Во-первых, DESFire EV3 для чувствительных зон: паркинг, служебные помещения, машинные отделения, коммерческие зоны. Он дороже, зато даёт более гибкую модель приложений и файлов, Common Criteria EAL5+ и современные механизмы вроде transaction timer.
Отдельно усилился аргумент против Classic-совместимых карт. В 2024 году Philippe Teuwen и Quarkslab разобрали static encrypted nonce у MIFARE Classic-compatible карт и показали аппаратные backdoor-ключи в распространённых FM11RF08S и совместимых чипах. Поэтому формулировка в ТЗ должна быть жёсткой: никакого Classic-compatible как целевого режима для новой СКУД.
Для архитектуры ключей я бы прямо указывал актуальные SAM-модули, например MIFARE SAM AV3: ключи остаются внутри защищённого модуля, наружу выходят только производные ключи и криптооперации.
Во-вторых, мобильные идентификаторы. Для новых объектов уже стоит закладывать сценарий, где житель открывает дверь телефоном или часами. Это не отменяет пластик, но уменьшает зависимость от дешёвых болванок и упрощает жизненный цикл доступа.
В-третьих, приёмка по модели угроз. В 2026 году нельзя принимать СКУД по словам «карты защищённые». Нужно проверять конкретные вещи: UID-only не открывает, сектор аутентифицируется, ключ не виден подрядчику, ротация описана, карты выпускаются через контролируемую процедуру.
Вывод
MIFARE Plus SL3 — хороший фундамент для массовой СКУД, но он не спасает сам по себе. Защиту создают диверсификация, SAM, грамотная приёмка считывателей и дисциплина вокруг мастер-ключа.
Если упростить до одного правила: не проверяйте номер карты, проверяйте владение секретом. Всё остальное — выбор конкретных карт, считывателей и поставщиков — должно подчиняться этому правилу.
