Системы контроля доступа (СКУД) встречают нас в жизни на каждом шагу: в офисах, домах, транспорте и почти в любой сфере ежедневного применения. За последние десятилетия СКУД прошли большой путь эволюции. В данной статье мы не очень глубоко разберём некоторые важные аспекты реализации СКУД c использованием OSDP Crypto.

Немного теории...

СКУД обычно состоит из считывателя какого либо идентификатора (карты, брелка, смартфона) и контроллера, к которому подключены считыватели, — он выполняет функции сбора и обработки полученной от считывателей информации.

Самые первые считыватели, появившиеся в конце 90-х годов имели целый зоопарк интерфейсов связи считыватель — контроллер. Кто как умел... Однако самый известный стандартный протокол — это WIEGAND. Протокол WIEGAND — это два сигнальных провода, на которых может быть логический 0 или 1. На одной линии низкий — это 0, на другой линии низкий — это 1. Обе линии высокий уровень — это ожидание низкого уровня или пауза.

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

Стали думать, как решить задачу и в итоге появился протокол обмена данными OSDP (Open Supervised Device Protocol).

Протокол OSDP основан на физическом интерфейсе RS-485. Общие правила построения очень похожи на широко известный в промышленной автоматизации протокол обмена MODBUS.

Опять немного теории

Протокол OSDP состоит из структурированных пакетов, посылаемых и принимаемых по стандартному последовательному полудуплексному порту. Принцип обмена Master‑Slave. В терминах OSDP Master называется Control Panel (CP), а Slave называется Peripheral Devices (PD). Пакеты разделяются временной паузой. Пауза кратна длительности стоп бита передачи. Может быть больше, но не меньше.

Пакет обязательно содержит следующие поля: маркер начала, команду, длину пакета, адрес назначения, данные, контрольную сумму пакета. Все, что нужно... Любое PD на линии имеет свой уникальный для этой линии адрес и умеет декодировать любой пакет. И свой и чужой, и посылку и ответ. На «свой» пакет устройство ответит пакетом ответа. Все остальные PD терпеливо ждут, пока CP разговаривает не с ними. Ждут своей очереди и занимаются своими задачами — ожиданием, обработкой и запоминанием считанных идентификаторов. Когда дойдёт очередь, можно будет передать идентификатор CP в ответ на свой запрос.

Помимо чтения данных из считывателя, протокол OSDP позволяет записывать в считыватель достаточно широкий набор разного рода данных. Даже файлы размером сотни килобайт.

На одну линию RS-485 можно подключить несколько десятков устройств и опрашивать их последовательно. Как правило, скорость обмена выбирается 9600 бод. Эта скорость достаточно толерантная к качеству линии и компромиссная с точки зрения пропускной способности. Но... На такой скорости, больше 8 устройств уже многовато. Вы поднесли карту к турникету, а он думает... Решение о предоставлении доступа принимает CP, а у него очередь на 16–32 страждущих... Поэтому не увлекаемся «елочными гирляндами».

Итак, есть протокол. Физический и логический. Стандарт формализовали, описали, ввели в оборот. Протокол понравился, прижился. Производители начали массово внедрять протокол в свои устройства. На сегодняшний день, почти все известные производители оборудования для СКУД имеют в своей линейке устройства с интерфейсом OSDP.

Всё бы ничего, но пакеты по линии RS-485 «ходили» совершенно незащищёнными. Если подключиться анализатором к линии RS-485 и читать все, что «летает» по линии, можно спокойно анализировать всё, что передаётся и принимается. В пакетах OSDP могут быть и ключи доступа к картам и другие важные параметры, которые ни при каких обстоятельствах не должны быть скомпрометированы.

Что можно сделать в такой ситуации?

Первое, что приходит в голову — зашифровать обмен. Но как быть со старыми устройствами, которые не поддерживают шифрование и могут оказаться на одной линии с устройствами, которые поддерживают шифрование? Для обеспечения такой вот совместимости были предложены разные методы, которые легли в основу новой редакции протокола OSDP. В конечном итоге, получился великолепный защищённый протокол обмена с функцией обратной совместимости.

Как устроен OSDP Crypto

Если коротко, то по сравнению с обычным OSDP гораздо сложнее. Посудите сами...

Самое первое, что должен знать контроллер (CP) — это кто с ним будет работать. Кто есть на линии и кто что умеет... Опрашиваем по очереди всех кандидатов, посылаем команду CMD_ID. Тут все стандартно. Как было. В ответ получаем следующую информацию: кто производитель, что за модель, серийный номер устройства, версия ПО и железа. Если по модели понятно, что криптография поддерживается, можно переходить сразу к установке защищенного канала. В противном случае просим считыватель прислать нам свои «скилы» командой CMD_CAP (capability). Получаем в ответ больше десятка параметров. Нас в первую очередь интересует размер буфера обмена и поддержка криптографии. Тут тоже все обычно, но...

Вот он, претендент... 128 байт буфер обмена, умеет карты читать, входы цифровые 2 штуки, индикация двухцветная, поддерживает криптографию. Модный, продвинутый красавец...

Ну что же, можно приступать к таинству установки защищенного канала...

Первый ход, как всегда, E2-E4. Генерируем и посылаем в считыватель случайное число командой CMD_CHLNG. В ответе (REPLY_CCRYPT) приняли целую «простыню». Тут и аналог ID report, и ответное случайное число и криптограмма. Всего 8+8+16 = 32 байта.

Проверяем ответ... Может, чужак? У нас еще нет настоящих сессионных ключей, поэтому криптограмма на временных, которые делаются из смеси фиксированного зашитого ключа плюс шаманство с ID Report. ID Report у разных считывателей не повторяется. Серийник уникальный. Поэтому даже на этом этапе одинаковых ключей для разных считывателей нет. Не получится по однотипным паттернам пакета найти повторения и закономерности, чтобы подобрать ключи.

В принятой в ответе криптограмме зашифрованы наши случайные числа. Их знают обе стороны. Поэтому — расшифровали и сравнили. Ура, получилось! Расшифрованные случайные числа сравнились успешно с теми, что у нас есть. Наш клиент! Не чужак. Можем продолжать...

Остался последний рывок. Создаем боевые сессионные ключи.

Посылаем CMD_SCRYPT. Данные команды — это криптограмма длиной 16 байт. Опять случайное число хитро зашифровали.

На стороне считывателя вычислили сессионные ключи и послали часть обратно, чтобы контроллер мог расшифровать то, что зашифровал считыватель.

В ответ на CMD_SCRYPT прилетит REPLY_RMAC_I. 16 байт. Тот самый ключ, что вычислил считыватель. Теперь у нас есть пара ключей. CP→PD одни ключи, PD→CP другие ключи.

Сессионные ключи готовы. Сессию можно считать установленной.

Лирическое отступление

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

Вернемся к нашей парочке:

Ключи есть. Можем начинать «боевой» обмен.

В протоколе OSDP есть команды с данными, а есть без данных (только заголовок и команда или статус выполнения команды). Что шифровать, если данных нет? Прям шифровать ничего не нужно (другие ничего не поймут), а вот подписать пакет можно и нужно. Хватит 4 байт. Называются эти 4 байта MAC. Контрольная сумма пакета вычисляется с учетом этих 4 байт. Просто так пакет не подменишь. Более простые считыватели просто пропустят этот пакет. Заголовок есть, адрес есть и он не мой, контрольная сумма в конце и пауза тоже есть. А что там в данных — не наше дело. Вот она — обратная совместимость проявилась…

Ну все, работаем, пока время сессии не истекло. Через время контроллер обращается зашифрованным пакетом, а ему в ответ: NAK. Мол, простите, я забыл ваши ключи… Давайте снова обменяемся. Да и сам контроллер может периодически отменять сессию с текущими ключами и инициировать новый обмен ключами, как было описано выше, и далее работать с новыми набором сессионных ключей. Таким образом сильно усложняется процесс подбора ключей, ведь ключи шифрования меняются достаточно часто, например раз в 10 минут.

В заключение, хотелось бы озвучить мое оценочное суждение: OSDP Crypto, пришёл надолго. Многие несовершенства обычного протокола OSDP, которые тормозили развитие сложных методов идентификации (биометрия, QR, смартфоны) устранены. Разве что скорость обмена по линии осталась медленной. Загрузить прошивку размером 150кб — та еще мелодрама из серий по 96 байт из которых полезных только 64. Возможно, в будущем или уже настоящем, появятся устройства, где RS-485 будет дополнен, например, транспортом UDP. Так сказать OSDP over IP/UDP. Пусть UDP пакет не защищен, пусть не гарантирована доставка, но зато очень быстро и дешево. Внутри пакета UDP будет пакет именно OSDP Crypto.

Вот такой получился обзор технологии OSDP Crypto.

Спасибо за внимание.

Это моя первая в жизни статья.