Спуфинг маяка - PullRequest
       11

Спуфинг маяка

0 голосов
/ 26 марта 2020

Предположим, у меня есть три смартфона, которые отправляют маяк с UUID: X. У двух из них есть приложение под названием True App: первое имеет мажор: 1, второстепенное: 1 второе имеет мажор: 1, минор: 2

Третий смартфон имеет приложение под названием Beacon Simulator, которое клонирует маяк двух других.

Первые два следует признать, что третий является подменяющим маяком.

лучший подход для решения этой проблемы для Android и iOS?

1 Ответ

0 голосов
/ 27 марта 2020

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

  1. Использовать вторичный переданный идентификатор

    Вы можете использовать вторичный известный идентификатор, который труднее скопировать (например, адрес bluetooth MA C), чтобы попытаться проверить, что идентификатор маяка поступил из ожидаемого источника. Этот метод редко работает хорошо , однако, поскольку решительный хакер может также подделать адрес MA C (или любое другое передаваемое поле) с соответствующим оборудованием. Использование этого подхода с адресом MA C также очень ограничено на мобильных устройствах - устройства iOS вообще не могут прочитать адрес MA C маяка, и оба передатчика Android и iOS периодически рандомизируют свои передатчики BLE.

  2. Хэши вращающихся идентификаторов

    Существует ряд систем маяков, которые пытаются избежать спуфинга с помощью специального формата маяка, в котором используется вращающийся идентификатор основанный на безопасном алгоритме хеширования криптографии c. Два примера этого - Gimbal (проприетарный) и Eddystone-EID (с открытым исходным кодом, но эффективно управляемый Google). В каждом случае вы должны позвонить на сервер, чтобы «разрешить» вращающийся га sh, который вы получаете от передачи маяка, и эффективно преобразовать его в идентификатор stati c, который может использовать ваше приложение. Этот подход достаточно безопасен для многих случаев использования, но есть серьезные недостатки : (a) Системы сложны и сложны в настройке. (б) Сетевое подключение требуется для разрешения идентификатора. Если вы потеряете связь или сеть работает медленно, ваше приложение не будет работать. (c) Этот подход блокирует вас для указания c поставщиков (Gimbal или Google). (d) Система все еще может быть побеждена путем записи передачи маяка в одном месте и ретрансляции ее во втором месте.

  3. Использование вторичных факторов для проверки обнаружения маяка

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

...