safetynet что это такое
990x.top
Простой компьютерный блог для души)
SafetyNet — что это такое?
Приветствую друзья. Данная статья расскажет о предназначении SafetyNet. Постараюсь написать простыми словами.
SafetyNet — что такое?
Специальная проверка, разработанная корпорацией Google, обеспечивающая безопасность устройств, работающих под операционной системой OS Android.
Суть: сервис SafetyNet автоматически проверяет работу установленных приложений смартфона, анализируя поведение используя машинное обучение, сравнивая с образцами из маркета Google Play. При обнаружении подозрительных действий — приложение блокируется, после удаляется.
Однако иногда сервис блокирует вполне легальные/безопасные программы.
Обход проверки SafetyNet заключается в установке менеджера Magisk Manager. Также необходим разблокированный загрузчик и кастомное меню рекавери. Запускаем менеджер, нажимаем слева на иконку три палочки, далее выбираем Загрузки, справа отобразится изображение увеличительного стекла и надпись Скрыть.
Кликаем Загрузить для компонента MagiskHide_Props_Config, устанавливаем, ожидаем завершение прокрутки текстового содержания. После инсталляции нажимаем Reboot, смартфон перезапустится. После выбрав пункт Модули заметите — компонент установлен:
После успешно пройденной проверки вы сможете пользоваться всеми функциями Google.
Заключение
Как заставить Google Pay работать на модифицированных смартфонах (SafetyNet Fix)
Таким образом, вся панорама модифицированных смартфонов исключается из этих функций, поскольку они больше не могут правильно работать на 360 °. Именно по этой причине в этом руководстве я хочу объяснить наиболее эффективный метод получения Исправление SafetyNet и вернитесь к использованию Google Pay и подобные системы также на модифицированные смартфоны. Этот метод действителен для всех марок телефонов, будь то Xiaomi, OnePlus, OPPO, Realme, Huawei, Samsung и т. Д.
Google Pay больше не работает? Вот исправление SafetyNet с Magisk
Что такое SafetyNet и как она работает
Представленная много лет назад сертификация SafetyNet является частью инструментов, интегрированных в сервисы Google Play. Последние состоят из пакета библиотек API для Android, к которым разработчики могут получить доступ для обеспечения совместимости между службами без ущерба для безопасности. Также по этой причине смартфоны без сертификации служб Google, как в случае с Huawei и Honor, не проходят тесты SafetyNet. В частности, библиотека называется API аттестации SafetyNet и был интегрирован, чтобы позволить разработчикам запускать свои приложения только на защищенных смартфонах. Таким образом, Google хочет предотвратить взлом конфиденциальных приложений, таких как платежные, банковские и т. Д.
Чтобы понять, является ли смартфон надежным, API аттестации SafetyNet оценивает целостность устройства как со стороны программного обеспечения, так и со стороны оборудования. Если вы хотите подробно понять, как работает этот процесс проверки, все подробности можно найти на Официальный сайт Android. Это означает, что сертификация не может быть получена от модифицированных смартфонов, то есть с загрузчик разблокирован и права root полученный.
Как проверить сертификацию SafetyNet
Начнем с того, что если вы разблокировали загрузчик и, возможно, также получили права root, вы не сможете пройти сертификацию SafetyNet. Прежде чем объяснять, как обойти этот блок, вам просто нужно загрузить одно из различных приложений из магазина Google Play, которое позаботится о проверке наличия или отсутствия этой сертификации. я использую SafetyNet Тест, но есть и другие, результат не меняется. После загрузки и установки вам просто нужно запустить его, чтобы продолжить проверку совместимости. Давайте посмотрим, например, что происходит на моем Xiaomi Mi 10T Pro с разблокированным загрузчиком, пользовательским восстановлением TWRP и включенными правами root:
Как видите, тест SafetyNet явно не проходит. На этом этапе давайте посмотрим, как приступить к решению извечной проблемы.
Как получить исправление SafetyNet с помощью Magisk
Предпосылка важна и необходима, когда дело доходит до этого типа процедуры. Модифицируя смартфон, вы должны знать, что делаете. Если Google попал в этот сертификат, то именно потому, что модифицированный смартфон гораздо более уязвим для хакерских атак. В результате использование в нем платежного или банковского приложения подвергает вас большему риску, чем «нормальные» пользователи. Следовательно, модифицируем ответственно.
1) Разрешения Root и TWRP
Хорошо, мы можем продолжить. Предполагая, что у вас уже разблокирован загрузчик, первое, что нужно сделать, это установить его. изготовленный под заказ восстановление альтернатива, такая как TWRP. Это программное обеспечение необходимо для установки приложений и инструментов, которые в противном случае невозможно было бы установить в стандартном режиме восстановления вашего телефона. И именно благодаря кастомному рекавери вам обязательно нужно будет получить права root, иначе вы не сможете продолжить. Если у вас есть смартфон Xiaomi, найдите наше общее руководство для обоих TWRP что для корень.
2) Установить Magisk
Благодаря TWRP и разрешениям root мы можем перейти ко второму шагу, который заключается в установке Magisk, ключевой инструмент, позволяющий воспользоваться преимуществами рутирования. В связи с этим я также приглашаю вас ознакомиться с моим руководством, в котором я объясняю, как улучшите свой смартфон с помощью лучших модулей Magisk. Но помимо этого, вот как действовать:
Отлично, теперь, когда вы установили Magisk на свой смартфон, пришло время воспользоваться им для исправления SafetyNet. Прежде всего, вам понадобится модуль Universal SafetyNet Fix и несколько небольших корректировок, чтобы получить желаемый результат:
Что ж, на этом этапе ваш смартфон должен успешно пройти тесты SafetyNet. Вы можете проверить это как из приложения, загруженного выше, так и из самого Magisk, нажав «Проверить SafetyNet«. Таким образом, ваш смартфон будет сертифицирован, и вы сможете вернуться к использованию Google Pay и всех тех приложений, которые требуют сертификации для работы.
Google положит конец рутингу Android
С новой версией SafetyNet некоторые приложения перестанут работать на устройствах, чьи владельцы получили права суперпользователя.
Одним из главных преимуществ ОС Android является ее открытость – пользователи могут сами выбирать лаунчеры и приложения по умолчанию. Многих также подкупает возможность получать на Android-устройствах права суперпользователя и устанавливать свои версии прошивки. Тем не менее, вскоре пользователи могут ее лишиться, так как Google намерена усилить безопасность своей мобильной ОС.
Процесс получения прав суперпользователя на Android-устройстве предполагает эксплуатацию уязвимостей. Для установки кастомизированной прошивки нужно разблокировать загрузчик ОС, что поддерживается (но не рекомендуется) некоторыми производителями электроники, в частности Sony. Однако последняя версия SafetyNet от Google будет воспринимать подобные действия как взлом.
SafetyNet представляет собой набор API, позволяющий приложениям проверять устройство на предмет компрометации. SafetyNet жизненно необходим банковскому и финансовому ПО, но и другие приложения (например, Pokemon GO и McDonald’s) тоже им пользуются. В прошлом фреймворки для получения прав суперпользователя на Android-устройстве наподобие Magisk могли использовать те же API, чтобы «убедить» приложения, будто смартфон не был взломан. Однако с новой версией SafetyNet они лишились такой возможности.
Как сообщают разработчики из XDA Developers, SafetyNet стал незаметно удостоверять аппаратное обеспечение с целью проверки целостности устройства. В частности, проверяется статус разблокировки загрузчика, наличие на устройстве ПО для получения прав суперпользователя и подписанных прошивок и пр. Другими словами, с обновленным SafetyNet скрыть от приложений факт взлома устройства практически невозможно.
Стоит отметить, что получать права суперпользователя и устанавливать кастомизированные прошивки по-прежнему можно. Тем не менее, в таком случае обращающиеся к SafetyNet приложения перестанут работать, и пользователям придется выбирать, что им важнее – права суперпользователя или работа с ключевыми приложениями.
SafetyNet Attestation — описание и реализация проверки на PHP
В эту тему пришлось детально погрузиться во время работы над обеспечением стандартных механизмов верификации устройств для разных мобильных платформ. Задача сводилась к разработке полноценной реализацию проверки JWS-токенов по протоколу SafetyNet на серверной стороне.
После многочасовых поисков и скрупулёзного изучения официальной документации Google решил поделиться полученным опытом. Потому что, кроме официальной документации, я нашел только отрывочные описания частных примеров реализации на разных ЯП. И ни намека на комплексное объяснение особенностей проверки по SafetyNet на сервере.
Статья будет полезна разработчикам, которые хотят подробнее разобраться с технологией верификации устройств по протоколу SafetyNet Attestation. Для изучения описательной части не обязательно знать какой-либо язык программирования. Я сознательно убрал примеры кода, чтобы сфокусироваться именно на алгоритмах проверки. Сам пример реализации на PHP сформулирован в виде подключаемой через composer библиотеки и будет описан ниже.
А в конце статьи — ссылка на разработанную мной библиотеку на PHP, которая обеспечивает полный цикл верификации JWS.
Дисклеймер: материал в явном виде содержит перевод официальной документации от Google с разъяснениями и описанием особенностей реализации, с которыми я столкнулся.
О технологии
Технология SafetyNet Attestation разработана Google как средство предоставления разработчикам мобильных приложений информации о надёжности приложения клиента при взаимодействии с сервером, который обслуживает мобильное приложение. Для этого в протоколе взаимодействия предусмотрен удостоверяющий сервис от Google, обеспечивающий верификацию, и представлены рекомендации по проверке ответа от удостоверяющего центра на стороне сервера.
Google пишет, что данный метод проверки не может исключить все принятые на сегодняшний момент методы защиты и верификации устройств. То есть SafetyNet не представляет собой единственный механизм защиты от небезопасного трафика, а создавался как дополнительный инструмент.
Что позволяет проверить технология:
Что именно вы являетесь автором приложения, которое сейчас взаимодействует с сервером.
Что в процессе взаимодействия клиента и сервера нет больше никого, кроме вашего приложения и сервера.
Что операционная система мобильного устройства не претерпела изменений, критичных для обеспечения безопасного обмена с сервером (не «заручено» — не взломано, а также то, что устройство прошло аттестацию совместимости с Android).
В каких случаях механизм не применим или не имеет смысла:
На устройстве пользователя отсутствует интернет, нет возможности связаться с удостоверяющим центром. В таком случае API выдаст ошибку на клиенте, и мы не сможем получить подписанный токен для проверки на сервере.
Если попытаемся выполнить верификацию подписанного токена в самом мобильном приложении (без участия сервера), так как проверка клиента не должна происходить на клиенте. Если у вас приложение без Backend, или вы в принципе не планируете верификацию SafetyNet на серверной части приложения, то нет смысла устанавливать и настраивать этот механизм проверки.
Если требуется детальное понимание статусов модификации системы, на которой работает мобильное приложение. В протокол заложен механизм однозначного определения модификации устройства. Он состоит из двух переменных: ctsProfileMatch и basicIntegrity. Об их назначении — чуть ниже.
Остальные пункты в рамках этой статьи, на мой взгляд, менее интересны. Общий принцип такой: если вам нужно что-то очень точное или что-то, что обезопасит контент, — ищите другой (дополнительный) способ защиты. Аналогично в случае, когда вы не собираетесь реализовывать проверку в нормальном порядке, как это задумано протоколом, или ваше приложение опирается на созданные уязвимости в конфигурации устройства.
Схематично процесс проверки клиента можно представить в виде схемы:
Рассмотрим поэтапно процесс верификации устройств по протоколу:
Инициация процесса проверки со стороны клиента.Отправка запроса от клиента на Backend на генерацию уникального идентификатора проверки (nonce) сессии. В процессе выполнения запроса на сервере генерируется ключ (nonce) сессии, сохраняется и передаётся на клиент для последующей проверки.
Генерация JWS-токена на стороне удостоверяющего центра.Клиент, получив nonce, отправляет его на удостоверяющий центр вместе со служебной информацией. Затем в качестве ответа клиенту возвращается JWS, содержащий информацию о клиенте, время генерации токена, информацию о приложении (хеши сертификатов, которыми подписывается приложение в процессе публикации в Google Store), информацию о том, чем был подписан ответ (сигнатуру). О JWS, его структуре и прочих подробностях расскажу дальше в статье.
Затем клиент передаёт JWS в неизменном виде на Backend для проверки. А на стороне сервера формируется ответ с информацией о результате прохождения аттестации.После получения статуса проверки JWS на стороне сервера обычно сохраняют факт проверки и, опираясь на него, влияют на функциональность положительным или негативным образом. Например, клиентам, не прошедшим аттестацию, можно отключить возможность писать комментарии, голосовать за рейтинг, совершать иные активности, которые могут повлиять на качество контента приложения или создавать угрозу и неудобство другим пользователям.
Описание процесса верификации на стороне сервера JWS от удостоверяющего центра
Документация Google в рамках тестирования на сервере предлагает организовать online-механизм верификации JWS, при котором с сервера приложения отправляется запрос с JWS на удостоверяющий сервис Google. А в ответе от сервиса Google содержится полный результат проверки JWS.
Но данный метод проверки JWS для промышленного использования не рекомендуются. И даже больше: для каждого приложения существует ограничение в виде 10 000 запросов в сутки (подробнее об ограничениях — здесь), после которых вы выгребите квоту и перестанете получать от него вменяемый ответ. Только информацию об ошибке.
Далее расскажу обо всём алгоритме верификации JWS, в том числе о верификации самих сертификатов (проверке цепочки сертификатов).
Подробнее о JWS
JWS представляет собой три текстовых (base64 зашифрованных) выражения, разделенные точками (header.body.signature):
В данном примере после расшифровки base64 получим:
Header :
Body:
Signature
Остановимся на том, что именно содержится во всем JWS.
Header:
alg — алгоритм, которым зашифрованы Header и Body JWS. Нужен для проверки сигнатуры.
x5c — публичная часть сертификата (или цепочка сертификатов). Также нужен для проверки сигнатуры.
Body:
nonce — произвольная строка полученная с сервера и сохранённая на нём же.
timestampMs — время начала аттестации.
apkPackageName — название приложения, которое запросило аттестацию.
apkDigestSha256 — хеш подписи приложения, которое загружено в Google Play.
ctsProfileMatch — флаг, показывающий прошло ли устройство пользователя верификацию в системе безопасности Google (основной и самый жёсткий критерий, по которому можно понять было ли устройство заручено и прошло ли оно сертификацию в Google).
apkCertificateDigestSha256 — хеш сертификата (цепочки сертификатов), которыми подписано приложение в Google Play.
basicIntegrity — более мягкий (по сравнению с ctsProfileMatch) критерий целостности установки.
Signature
Бинарная сигнатура, с помощью которой можно сделать заключение, что тело сообщения JWS было подписано с использованием сертификатов (цепочки сертификатов) указанных в Header, и с использованием известного нам приватного ключа. Ключевое — позволяет понять, что в цепочке взаимодействия нет никого, кроме нас и удостоверяющего центра Google.
Проверка сертификатов
Перейдём к непосредственной проверки каждой части полученного JWS. Начнём с сертификатов и алгоритма шифрования:
1. Проверяем, что алгоритм, с помощью которого подписано тело, нами поддерживается:
2. Проверяем, что сертификат (цепочка сертификатов), содержащиеся в Header (поле x5c), удовлетворяют нас по содержимому (загружаются в качестве публичных ключей):
3. Валидируем сигнатуру сертификата (цепочки сертификатов):
4. Сверяем hostname подписавшего сервера с сервером аттестации Google (ISSUINGHOSTNAME = ‘attest.android.com’):
Верификация тела JWS
Самый значимым пункт для определения характеристик, участвующего в обмене устройства с приложением. Что нам нужно проверить на данном этапе:
Тут все просто. Распаковали JWS, получили в Body nonce и сверили с тем, что у нас сохранено на сервере:
2. Проверяем заручено ли устройство, с которого происходит запрос.
Тут нужно принять решение, на что вы будете опираться для закрытия того или иного функционала пользователей, не прошедших эту проверку.
Есть два параметра, на основе которых можно принимать решение о надежности устройства: ctsProfileMatch и basicIntegrity. ctsProfileMatch — более строгий критерий, он определяет сертифицировано ли устройство в Google Play и верифицировано ли устройство в сервисе проверки безопасности Google. basicIntegrity — определяет, что устройство не было скомпрометировано.
3. Проверяем время начала прохождения аттестации.
Тоже ничего сложного. Нужно проверить, что с момента ответа от сервера Google прошло немного времени. По сути, нет чётких критериев прохождения теста — с реферальным значением нужно определиться самим.
4. Проверяем подпись приложения.
Здесь тоже два параметра: apkDigestSha256 и apkCertificateDigestSha256. Но apkDigestSha256 самой Google помечен как нерекомендуемый способ проверки. С марта 2018 года они начали добавлять мета-информацию в приложения — из-за чего ваш хеш подписи приложения может не сходиться с тем, который будет приходить в JWS (подробнее — здесь).
Поэтому единственным способом проверки остается проверка хеша подписи приложения apkCertificateDigestSha256. Фактически этот параметр нужно сравнить с теми sha1 ключа, которым подписываете apk при загрузке в Google Play.
5. Проверяем имя приложения, запросившего аттестацию.
Сверяем название приложения в JWS с известным названием нашего приложения.
Верификация сигнатуры
Здесь нужно совершить одно действие, которое даст нам понимание того, что Header и Body ответа JWS подписаны сервером авторизации Google. Для этого в исходном виде склеиваем Header c Body (с разделителем в виде «.») и проверяем сигнатуру:
Вместо заключения. Библиотека на PHP
Уже после решения задачи и отдельно от нашей кодовой базы, я разработал библиотеку на PHP, которая обеспечивает полный цикл верификации JWS.
Её можно скачать из Packagist и использовать в своих проектах.
Международный сервис SafetyNET
Международный сервис SafetyNET является элементом Глобальной Морской Системы Связи и для Обеспечения Безопасности (GMDSS).
SafetyNET это Международный сервис, служащий для передачи информации бедствия, срочности и безопасности на районы NAVAREA и отдельные районы Coastal area через Международную Мобильную Спутниковую Организацию (Inmarsat). Информация передается бесплатно и обязательна для приема всеми судами всех флагов при плавании в этих районах.
Информационный поставщик (районный координатор) пересылает ИБМ для данной области на Inmarsat-C Береговую Земную Станцию (CES). CES передает ИБМ через спутниковую сеть для спутника, обслуживающего конкретный океанский район. Прием осуществляется приемником расширенного группового вызова (РГВ) (EGC – Enhanced Group Call). Суда могут получить SafetyNET ИБМ везде, независимо от их расстояния до CES или ИП;
Технически распространение информации SafetyNET осуществляется в системе Расширенного Группового Вызова, являющейся в свою очередь частью системы Inmarsat.
В системе РГВ передаются также необязательные для приема коммерческие сообщения FleetNET, а также системные сообщения по работе станций Inmarsat (System Messages).
Система РГВ обеспечивает автоматическую передачу сообщений SafetyNET всем судам в океанские районы NAVAREA, либо в заданные географические районы в виде окружностей или прямоугольника. Передачи осуществляются по расписанию или вне расписания для срочных сообщений.
Информация в системе РГВ передается на так называемом общем канале (Common Channel) и может быть принята специальным судовым приемником РГВ (EGC). Сообщения РГВ могут быть адресованы отдельным судам, флоту, судам в районе NAVAREA, судам одного флага или всем судам океанского района.
Зоны охвата четырех спутников Inmarsat определяют четыре океанских района, в пределах которых судно по EGC может принять передачи SafetyNET:
— Восточный район Атлантического океана (AOR-E);
— Район Индийского океана (IOR);
— Район Тихого океана (POR);
— Западный район Атлантического океана (AOR-W).
Спутники Inmarsat покрывают практически весь Мировой океан, за исключением полярных районов (выше 76 0 N и 76 0 S).
Особенностью спутниковой связи является то, что на качество приема практически не влияют координаты судна в пределах океанского района, атмосферные условия и время суток. Достоверность приема информации обеспечивается техникой кодирования с исправлением ошибок. В нормальных условиях ошибки отсутствуют вообще или очень редки.
Только Информационные Поставщики (ИП), одобренные IMO, IHO, WMO (Всемирной Метеорологической Организацией) могут дать разрешение для передачи SafetyNET.
В состав информации, передаваемой по каналам SafetyNET, входят:
— метеорологические предупреждения и метеопрогнозы;
— сообщения о бедствии в направлении берег – судно, информация по поиску и спасению;
— предупреждения о нападениях пиратов;
— данные по корректуре карт (в стадии разработки) и другая срочная информация.
Международная система NAVTEX
NAVTEX (навигационный телекс) – международная автоматизированная система передачи в режиме узкополосного буквопечатания навигационной, метеорологической и другой срочной информации, относящейся к прибрежным водам в радиусе до 400 миль от берега. NAVTEX также обеспечивает передачу метеорологических прогнозов и всех штормовых предупреждений.
NAVTEX является компонентом Всемирной службы навигационных предупреждений (ВСНП), и входит в состав ГМССБ. Схема организации НАВТЕКС представлена в [Ш].
NAVTEX это одночастотная сеть радиовещания по расписанию с автоматическим приемом и устройством, производящим отбор принимаемых, и исключение принятых ранее сообщений.
Международная служба NAVTEX осуществляет координированную передачу и автоматический прием на специально выделенной для этих целей частоте 518 кГц. Используется класс излучения F1B, FEC Collective.
Береговые станции передают информацию на английском языке.
В некоторых районах могут использоваться национальные службы NAVTEX, осуществляющие передачи на частотах 490 кГц и 4209,5 кГц.
Каждая береговая станция обслуживает определенный район. Для уменьшения помех между передающими станциями расписания передач учитывают относительное географическое положение всех береговых станций NAVTEX в районе. Передачи разносятся по времени в соответствии с матрицей передач.
Передатчик обеспечивает дальность приема передач судовыми приемниками NAVTEX до 250 – 400 миль.
На судне ИБМ автоматически выводится на печать со специализированного приемника.
Там, где береговая область не покрывается сервисом NAVTEX, например вокруг Австралии, ИБМ для этой области будет передаваться через SafetyNET.