Как программно аутентифицировать API подключения?

#java #android #google-nearby #google-nearby-connections

#java #Android #google-поблизости #google-nearby-connections

Вопрос:

Мне приходится взаимодействовать с более чем двумя устройствами, которые отлично работают с подключениями Google NearbyAPI. Теперь мне нужно защитить соединение, ограничивающее доступ к кластерной сети. API предоставляет метод аутентификации устройств, который используется с токеном, предоставляемым библиотекой, однако этот токен предназначен для авторизации двумя пользователями в пользовательском интерфейсе. Мне нужно сделать это программно, пользователь не должен этого делать.

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

Что я пытался сделать:

Поскольку я не вижу способа, заявленного в документах, сделать это, не попросив пользователя принять соединение, которое я пробовал:

  • Ввод секрета в конец конечной точки

    id-secret Таким образом, каждое устройство должно расшифровать секрет и проверить, соответствует ли информация зарегистрированной, а затем принять соединение. Но шифрование с использованием AES требует создания большой полезной нагрузки, и это приводит к тому, что устройства не обнаруживаются. Я не пробовал использовать TDE, поскольку это предполагает меньшую полезную нагрузку, но я не уверен, что это правильный путь.

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

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

Ответ №1:

На данный момент вам нужно сначала принять подключение, а затем сразу же выполнить запрос / ответ. Он не самый чистый, но все равно будет в безопасности.

Вещательная идентичность

Я бы рекомендовал добавить уникальный идентификатор к имени / информации конечной точки. например. «12345: Will». Таким образом, устройство имеет стабильный идентификатор, на который вы можете ссылаться. Чтобы сделать это еще более безопасным, вы можете солить идентификатор. например. «12:54321:Will» или «$ {salt}: $ {hashedId}: $ {name}». Чтобы разрешить хэшированный идентификатор, вам нужно будет перебрать все известные идентификаторы на вашем устройстве и запустить sha (соль идентификатор).ограничение (5) до тех пор, пока один из них не совпадет с Хашидом. Таким образом, реклама меняется каждый раз, когда соль вращается, и отследить устройство становится сложнее. Бонусные баллы, если вы также скрываете имя.

Обеспечение безопасности соединения

Немедленно примите соединение, не проверяя токен авторизации. Пока не отправляйте личную информацию, так как соединение небезопасно. Оба устройства должны запустить таймер (1 ~ 5 секунд) и отправить вызов другой стороне. Вызов должен каким-то образом включать токен аутентификации. например. PrivateKey.sign(authToken). Вы также можете выполнить проверку в обоих направлениях, поэтому вы также можете включить открытый ключ. например. localPrivateKey.sign(sharedAuthToken remotePublicKey). Если обе стороны подтвердят это в течение установленного срока, соединение можно считать безопасным.

Отказ от ответственности: я работаю на близлежащих соединениях

Комментарии:

1. Скоро мы представим «необработанный токен аутентификации», который намного длиннее текущего токена и создан именно для этого варианта использования. Если вы используете короткий 5-символьный токен аутентификации, вредоносное устройство может повторно подключаться к 2 допустимым устройствам, пока оба его соединения не будут использовать один и тот же 5-символьный токен аутентификации. Оттуда он может пересылать сообщения между ними, чтобы обойти запрос / ответ. Чтобы избежать этого, вам нужно либо явно ограничить соединения, не принимая новые соединения в течение ~ 5 секунд, либо дождаться более длинного токена, чтобы сделать эту атаку намного сложнее.

2. Спасибо за ваш ответ! Я попробую ваш алгоритм. Есть ли у вас какие-либо идеи, когда будет выпущен необработанный токен аутентификации?

3. Надеюсь, в январе. Код готов, поэтому мы просто ждем, когда кто-нибудь освободится, чтобы отправить обновленный SDK.