Какой самый простой протокол для безопасного подключения аппаратного устройства к сети? - PullRequest
0 голосов
/ 08 августа 2011

После разгрома Sony PSN я пытаюсь найти примеры безопасного подключения к сети. В частности, есть два варианта использования:

1 - компьютер загружает программное обеспечение, которое затем уникальным и безопасным образом маркирует его в облачной службе 2- производитель оборудования однозначно маркирует аппаратное устройство, которое затем согласовывает членство в сети.

Учитывая тот факт, что аппаратное устройство, возможно, придется менять (отзывать или улучшать обслуживание), создается впечатление, что # 2 становится # 1.

В общих чертах это так: - подключиться к сервису через HTTPS для защиты от человека посередине - устройство генерирует GUID и представляет его через HTTPS для обслуживания - сервисные записи GUID против аккаунта - в случае успеха услуга «включает» устройство

Но как защитить GUID, чтобы его нельзя было украсть?

Ответы [ 2 ]

2 голосов
/ 08 августа 2011

Я просто хотел прокомментировать здесь:

Проблемы Sony с PSN начались с ужасной практики в отношении среды QA.

Во-первых, они по умолчанию доверяли всему, что было отправлено на эти серверы с помощью инструментария разработчиков. Причина, по которой они это сделали, заключалась в том, что комплект разработчика стоил более 10 тысяч долларов США, и поэтому они думали, что любой, кто заплатит эту сумму, будет взлетать. Однако, когда они радикально понизили цену, все изменилось внешне, и они не учли этого.

Вторая проблема с PSN заключалась в том, что безопасность между QA и live была, в лучшем случае, слабой, и ее легко обойти. Насколько я понимаю, вы можете отправлять команды жить, используя учетные данные QA. Поскольку использовались учетные данные QA, все платные действия были одобрены без передачи денег, а действия были применены к реальным счетам. Когда несколько человек сказали Sony об этом, они ничего не сделали.

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

Суть в том, что Sony вырыла на нем свою могилу, чтобы я не использовал все, что они сделали, в качестве шаблона для того, как делать что-то. Черт, многие их сайты были открыты для SQL-инъекций, которые в наши дни должны уволить вас.


Другим примером здесь является iPhone. Каждый iPhone имеет уникальный идентификатор, который установленные приложения могут захватывать и отправлять обратно по сети; похож на серийный номер. Некоторые приложения используют этот идентификатор, чтобы попытаться привязать конкретное устройство к человеку. Тем не менее, тривиально создать идентификаторы и транслировать их, так что это не очень хорошо сработало для партнеров. Кроме того, Apple не предоставляет способ гарантировать, что данный идентификатор (UUID) действителен для производителей приложений.


Третий пример - операторы мобильной связи. Они используют определенный идентификатор, указанный на вашей SIM-карте, чтобы идентифицировать вашу учетную запись, чтобы знать, кому выставлять счет при совершении звонка. Этот идентификатор проверяется всякий раз, когда телефон регистрируется в сети. Однако мы имеем дело с радиосигналами, и любое устройство, которое может транслировать правильный идентификатор, может получить доступ. Дело в том, что честные люди думают, что только AT & T одобренные устройства могут подключаться к сети AT & T. Реальность такова, что все может, но они собираются выставить счет владельцу определенного удостоверения личности ...

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


Куда мы пойдем отсюда?

На базовом уровне вы связываете идентификатор с учетной записью в вашем сервисе. PSN, Apple и другие сделали это. Когда ID транслируется, вам необходимо убедиться, что он существует и привязан к активной учетной записи. Если оба пройдут, у вас есть два варианта: либо выполнить запрошенное действие, либо запросить дополнительную проверку.

Для любых действий, требующих потраченных денег, выполните дополнительную проверку (обычно в виде имени пользователя / пароля), соберите средства и выполните действие. Сделайте еще один шаг, и каждый раз, когда вводится неправильный логин, отправляйте электронное письмо пользователю. Далее автоматически отправляем квитанцию. Обычно это делается для того, чтобы ваши честные пользователи могли узнать, когда что-то происходит.

Все остальное просто пропущено.

Разумеется, имея в виду, что учетные данные QA НЕ должны работать в вашей среде Live. Эти системы не должны быть привязаны друг к другу ни при каких условиях и, честно говоря, должны даже работать на отдельном оборудовании. Другими словами, QA и Live не должны совместно использовать базу данных для входа.


Дело в том, что вам не нужно заботиться о самом устройстве; просто аккаунт. Вы не можете управлять устройством, так как оно не в ваших руках; черт возьми, вы даже не можете быть уверены, что это не было физически подделано. (XBox боролся с этим, когда люди добавляли резисторы или сжигали определенные компоненты, чтобы избавиться от физических функций безопасности).

Итак, ИМХО, сделайте немного, чтобы честные люди были честными, но в целом не переживайте по этому поводу. Теперь вы должны передать все через SSL или другое зашифрованное соединение между устройством и вашим облаком, чтобы не пропускать идентификаторы никому, кто хочет их захватить. Это поможет защитить тех честных людей.

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

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

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


Это было долго наматываться. Но моя точка зрения такова:

  1. Вы не можете защитить удостоверение личности или что-либо еще, что вы раздали.
  2. Вы не можете гарантировать, что запросы поступают с ваших устройств или с ваших собственных утвержденных устройств.
  3. Вам лучше предпринять действия, чтобы разделить контроль качества и производство для тех, кто разрабатывает программное обеспечение для этих устройств, используя ваши службы.
  4. Лучше принять меры для защиты своих обычных честных пользователей.
  5. НИЧЕГО не верь.
  6. В связи с вышеизложенным вы должны оценить свою бизнес-модель, чтобы вам было все равно, какое устройство использовалось, и вместо этого сосредоточиться на самих отдельных учетных записях; которую вы действительно контролируете.
1 голос
/ 08 августа 2011

Я не уверен, что полностью понимаю вопрос, но я думаю, что вы хотите, чтобы какое-то устройство поддерживало GUID, назначенный ему веб-службой, и вы не хотите, чтобы кто-то узнал, что это за GUID, исправить?

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

Короче говоря, невозможно полностью спрятаться. Кто-то всегда может перепроектировать это. Есть люди, которые читают данные прямо из памяти с помощью аппаратного обеспечения.

...