id: Гость   вход   регистрация
текущее время 21:16 28/03/2024
Автор темы: _owl, тема открыта 17/11/2016 14:58 Печать
Категории: криптография, аутентификация, хард, смарт-карты, разное, офф-топик
https://www.pgpru.com/Форум/ПрактическаяБезопасность/КакИспользуютсяNFCМеткиВУдостоверенияхЛичности
создать
просмотр
ссылки

Добрый день!


собрались в организации изготовить служебные удостоверения для сотрудников. Есть вариант встроить в "корочки" NFC метку. Понятно что на нее можно записать некий статический идентификатор и считывать его на смартфон или спец. устройство. Затем программа будет "лезть" в базу данных и по этому идентификатору искать запись про данного сотрудника и показывать те или иные данные оператору.


это простейший вариант. есть ли другие? можно ли например записать на метку данные владельца, подписанные ключем организации? фотографию? PGP ключ или его отпечаток? Может ли она хранить не статическую цифру, а работать по алгоритму запрос-ответ (challenge-response)?


Вообще на сколько целесообразно наличие такого чипа в удостоверении и каковы сценарии его использования?


Спасибо!


 
Комментарии
— SATtva (17/11/2016 15:17)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Вы уверены, что речь об NFC, а не об RFID? Первое — не метка, а протокол передачи данных (то же, что WiFi или Bluetooth, но с маломощным передатчиком, работающим на совсем малых дистанциях), гонять через него можно что душе угодно. У Вас же там всё-таки, по-видимому, RFID — это просто идентификатор, который, будучи помещённым в магнитное поле, передаёт некоторую зашитую в него битовую последовательность.

Существуют более сложные RFID-метки с собственным процессором на борту, которые способны самостоятельно выполнять простые математические или криптографические операции для challenge-response-протоколов (чтобы не передавать секрет в эфир). Всё зависит от возможностей конкретной модели устройства.


Цель — бесконтактная аутентификация. Насколько она целесообразна в конкретно Вашем случае — вопрос к руководству организации, у меня недостаточно информации, чтобы на него отвечать.
— _owl (09/12/2016 09:07)   профиль/связь   <#>
комментариев: 105   документов: 20   редакций: 3
цель организации – да, безусловно аутентификация работников. Безконтактность приветствуется, но не ставится "во главу угла". на данном этапе не предполагается разворачивания систем типа по безконтактным меткам пропускать человека в здание, отслеживать его положение и автоматически маршрутизировать телефонные звонки в то помещение где он в данную минуту находится.

скорее применение NFC (или RFID) – попытка получения дополнительного недорогого инструмента проверки подлинности удостоверения, верификации личности его владельца. Сценарий примерно такой. Где-то, скорее всего в условиях отсутствия подключения к Интернет и к общей сети организации, человек проходит через КПП и предъявляет удостоверение. сотрудник службы безопасности организации должен в ограниченное время принять решение пропустить/не пропустить. Подлинное удостоверение или нет. Одним из таких способов проверки видится следующее.

Информация о владельце удостоверения и о самом удостоверении (ФИО, должность, номер удостоверения, срок действия, UID встоенной NFC карточки) компонуется в электронной форме и подписывается криптографическим ключом организации. Затем блок информации и подпись шифруется другим ключом и зашифрованный блок записывается в память NFC метки. При проверке удостоверения сотрудник СБ считывает информацию на свой планшет. Расшифровывает текст, проверяет электронную подпись организации и сличает данные владельца удостоверения из криптографически подписанного блока с данными, напечатанными на удостоверении. Совпадает – значит владелец "правильный". Не совпадает – соответственно...

Планшет сотрудника СБ может быть в оффлайн-режиме и с усиленными настойками безопасности. Естественно потребуется некое разработанное "на заказ" приложение, которое будет в автоматическом режиме проделывать все описанные операции. на планшете должен быть записан закрытый ключ которым шифруется передаваемая информация и публичный ключ организации, для проверки электронной подписи. Шифрование передаваемой информации помогает избежать несанкционированного считывания данные о владельце удостоверения.

Пока нам видится вот такой алгоритм использования. Конструктивная критика приветствуется!
— _owl (09/12/2016 09:30)   профиль/связь   <#>
комментариев: 105   документов: 20   редакций: 3
кстати есть еще один элемент удостоверения, который можно как-то увязать с информацией на NFC метке – это баркод. он является машино-читаемым, тот же планшет сотрудника СБ может распознать упакованную туда информацию. Но что туда упаковывать? Чаще всего, на сколько мы понимаем, это строка типа ФИО+№ удостоверения + контрольная сумма. "Контрольная сумма" может быть просто CRC от предыдущего текста. Можно наверное использовать более сложные вещи типа алгоритма Луна или Верхуффа. Но все это – не более чем проверка наличия ошибки в предшествующем тексте (ФОИ+номер). Ничего не дает с точки зрения подтверждения подлинности удостоверения.

Можно рассчитывать значение контрольной суммы одним из названных способов. Затем, используя значение контрольной суммы и некий наперед выбранный параметр – "секрет организации" – вычислять значение какой-то подходящей математической функции. И результат заносить в бар-код. Например брать логарифм от "суммы" по основанию "секрет". Тогда планшет сотрудника СБ, снабженный соответствующей программой, сможет проверить соответствие. Вопрос: какую лучше использовать "секретную" функцию и какие свойства должны быть у "секретного" параметра?

А можно вообще как то увязать данные с NFC карты (например SHA512-хэш) от всего что там записано, плюс ФИО+номер, и как-то это упаковывать в баркод. В общем пока сырой полёт фантазии...

Буду признателен за любые конструктивные советы.
— SATtva (09/12/2016 09:51)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

Совпадает — значит, какой-то чувак с антенной записал предыдущий сеанс аутентификации и сделал дубликат карты. В Вашем протоколе отсутствует защита от повторной передачи.
— _owl (09/12/2016 11:05)   профиль/связь   <#>
комментариев: 105   документов: 20   редакций: 3
Да, если чувак с антеной сделает карту с таким же UID. поскольку UID NFC карты вносится в подписываемый блок данных, то при верификации программа на планшете сотрудника СБ сравнит фактический UID карты удостоверения с UID, внесенным в криптографически подписанный блок данных. Если различаются – у чувака нужно отнять антенну...

пока не представляю себе на сколько сложно сделать/купить карту с наперед заданным UID. Наверное это возможно, как в случае IMEI телефонов. Но проблем чуваку с антенной добавит, т.е. стоимость подделки возрастёт. Да и записать сеанс связи с NFC картой – дело хлопотное, нужно считыватель расположить не далее 10 см от удостоверения. Плюс можно в корочки встроить специальный текстиль или просто фольгу, и тогда считать что-то можно только при раскрытом удостоверении. Продавцы NFC говорят что это реально.
— SATtva (09/12/2016 11:11)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Тогда зачем Вы вообще заморачиваетесь с криптографией, если в итоге начинаете полагаться на авось?
— _owl (09/12/2016 11:25, исправлен 09/12/2016 11:25)   профиль/связь   <#>
комментариев: 105   документов: 20   редакций: 3

Потому что это обсуждение не завершенного пока алгоритма, включающего в себя как технические, так и организационные аспекты. Вполне допускаю, что при более глубоком изучении вопроса окажется, например, что карты NFC, включая их UID, клонировать достаточно легко, а вот например UHF – очень сложно. И, собственно, чтобы получить советы такого рода, и максимально устранить "авось" из нашего решения, мы и обсуждаем его здесь, на форуме.


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

— _owl (09/12/2016 12:51)   профиль/связь   <#>
комментариев: 105   документов: 20   редакций: 3
В Вашем протоколе отсутствует защита от повторной передачи.


SATtva, а какие методы защиты от повторной передачи здесь можно применить?
— sentaus (09/12/2016 13:30)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
пока не представляю себе на сколько сложно сделать/купить карту с наперед заданным UID.

А почему это должна быть именно карта? Аутентифицирующее устройство(сервер) ведь не карту видит, а всего лишь радиоволны. А уж что является их источником – это вопрос.

какие методы защиты от повторной передачи здесь можно применить?

Наверно какой-то challenge-response в любом виде. Сервер выдаёт уникальную случайную строку, которую карта должна "подписать"
— SATtva (09/12/2016 13:59)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

Challenge-response, rolling code и т.п. или one-time shared key (неавтономная схема, требует доступ к бекэнду в процессе аутентификации).
— _owl (09/12/2016 16:29)   профиль/связь   <#>
комментариев: 105   документов: 20   редакций: 3
Challenge-response, rolling code и т.п. или one-time shared key


это реализуемо, такие метки есть. Но они требуют специализированных считывателей. Обычным планшетом здесь уже не обойдешься, и общая стоимость системы существенно вырастет. Поэтому, наверное, будем планировать такие штуки уже в "системе версия 2.0". В любом случае, спасибо SATtva!

А почему это должна быть именно карта? Аутентифицирующее устройство(сервер) ведь не карту видит, а всего лишь радиоволны.


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

Если есть идеи, посоветуйте пожалуйста как извлечь наибольшую пользу из наличия баркода. Конкретнее, повторюсь:
Можно рассчитывать значение контрольной суммы одним из названных способов. Затем, используя значение контрольной суммы и некий наперед выбранный параметр – "секрет организации" – вычислять значение какой-то подходящей математической функции. И результат заносить в бар-код. Например брать логарифм от "суммы" по основанию "секрет". Тогда планшет сотрудника СБ, снабженный соответствующей программой, сможет проверить соответствие. Вопрос: какую лучше использовать "секретную" функцию и какие свойства должны быть у "секретного" параметра?
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3