Спасибо за развернутую дискуссию. По сути просто несколько добавлений:
Во первых о какой угрозе идет речь, и во вторых для этого вовсе не обязательно серверу каждый раз использовать ресурсы клиента для подобной проверки, серверу достаточно самому напрямую без ухищрений спросить об этом у всезнающего сервиса.
Проверку вполне достаточно провести один раз при инициации процесса обмена. Это позволит отделить дешевого бота от разумного белкового пользователя. Ключевое слово «дешевого».
Про «спросить об этом у всезнающего сервиса» — да у Google есть интерфейс валидации на их стороне. Но этот интерфейс имеет RateLimit в 10 000 запросов в сутки и как написано в статье — для более-менее нагруженного сервиса — это очень мало, из-за чего приходится реализовывать полноценную проверку собственными силами (опять же по рекомендации Google)
Клиент начинает процесс и получает nonce с сервера, и он же (клиент) отправляет nonce гуглу.
— Сервер с гуглом не общается при этом?
На этом шаге действительно не общается. Полученный от сервера nonce отправляется Google
Клиенту возвращается JWS, с информацией о нем же самом, т.е. о клиенте.
— Сервер и тут не общается с гуглом? Нужна ли информация клиенту о нем же? И почему время начинается от гугла, а не от сервера?
Клиенту нет не нужна. Но нужно серверу для того что бы понять что об этом клиенте думает Google.
Клиент отправляет JWS в неизменном виде на Backend для проверки.
— На этом этапе Клиент точно не меняет ничего? даже время?
Клиент ничего не меняет и отправляет JWS в неизмененном виде. Если клиент что то поменяет — ему придется подписать JWS своим каким-нибудь сертификатом — о чем мы сразу узнаем на бекенде и отклоним аттестацию.
На стороне сервера: анализ того что прошло через руки клиента? И тут сервер тоже не общается с гуглом? (ну хотя бы проверки ради)
Вся верификация клиента происходит на основании данных полученных от клиента, или прошедших через клиента, т.е. еще до того как будет сделан вывод по верификации, сервер полагает что эти данные верны и неподдельны, презумпция?
Как я написал выше — если клиент попробует что то поменять ему придется подписать новый JWS своим сертификатом — о чем мы узнаем при проверке цепочки сертификатов и верификации сигнатуры. Это нам гарантирует что данные не претерпели изменения в процессе передачи. И нужно понимать что эта процедура изначально предусмотрена для того что бы сделать заключение о клиенте. Если он верификацию не пройдет — значит не пройдет, мы сделаем соответствующий вывод о приложении которое сейчас взаимодействует с сервером. И да в этом процессе сервер по прежнему никак не общается с Google сервисом, это и не нужно нам вполне достаточно проверить цепочку сертификатов и сигнатуру что бы понять что никто кроме гугла не подписал JWS.
И что позволяет проверить технология:
Что именно вы являетесь автором приложения, которое сейчас взаимодействует с сервером.
— Конечно же я, но только вот кто же я, то ли я это клиент, то ли не клиент?
Предполагается что «я» — это компания которая контролирует и серверную часть и отвечает за код запущенный на клиенте в том виде в котором он доступен из Google Play.
Что в процессе взаимодействия клиента и сервера нет больше никого, кроме вашего приложения и сервера.
— На чем основан такой вывод? из статьи ничего этого не видно.
На том что в цепочке сертификатов нет ничего лишнего (никто не модифицировал тело JWS) — ни чьих кроме Google сертификатов. И на основании того что валидируется сигнатура с использованием корневого Google сертификата.
Есть два параметра, на основе которых можно принимать решение о надежности устройства: ctsProfileMatch и basicIntegrity.
ctsProfileMatch — более строгий критерий, он определяет сертифицировано ли устройство в Google Play и верифицировано ли устройство в сервисе проверки безопасности Google.
basicIntegrity — определяет, что устройство не было скомпрометировано.
— И тут не все ясно, сервис может подтвердить что когда то устройство было зарегистрировано у них, всего лишь. А было ли оно скомпрометировано или нет откуда гуглу это ведомо?
Что операционная система мобильного устройства не претерпела изменений, критичных для обеспечения безопасного обмена с сервером (не «заручено» — не взломано, а также то, что устройство прошло аттестацию совместимости с Android).
— Вообще ничем не подтвержденный предосудительный рекламный вывод, ведущий в обман доверчивого читателя?
Тут к сожалению мне сказать нечего — это алгоритмы Google. При реализации верификации я опирался исключительно на документацию. По сути сам Google говорит что данный способ не может быть самостоятельным и полностью опираться на него при принятии решения о надежности клиента не стоит. Вы (Мы) всегда в праве придумать собственным механизм оценки клиента, кто ж мешает.
И еще вопрос: сервер самостоятельно без гугла не может провести всю процедуру, рассчитывая и опираясь на себя самого, а не на чей то посторонний авторитет, и доверяя только себе?
Это предложение гугла, который собственно и заинтересован в сборе информации не обязательно его касающейся, стоит ли идти в капкан?
Ну частично ответил выше. А про капкан — это очень интересный вопрос) Этот вопрос стоит задать самому себе, каждому из нас, стоя в очереди в кассу за новым телефоном/планшетом/чайником.
Может и в принципе не стоит использовать этот алгоритм — придумывайте свой. Другой вопрос в стоимости решения.
Да это верно. По сути следует ограничить список допустимых алгоритмов, подсоберу комментарии и сделаю в следующей версии ограничение вместе с остальными правками. Спасибо!
Проверку вполне достаточно провести один раз при инициации процесса обмена. Это позволит отделить дешевого бота от разумного белкового пользователя. Ключевое слово «дешевого».
Про «спросить об этом у всезнающего сервиса» — да у Google есть интерфейс валидации на их стороне. Но этот интерфейс имеет RateLimit в 10 000 запросов в сутки и как написано в статье — для более-менее нагруженного сервиса — это очень мало, из-за чего приходится реализовывать полноценную проверку собственными силами (опять же по рекомендации Google)
На этом шаге действительно не общается. Полученный от сервера nonce отправляется Google
Клиенту нет не нужна. Но нужно серверу для того что бы понять что об этом клиенте думает Google.
Клиент ничего не меняет и отправляет JWS в неизмененном виде. Если клиент что то поменяет — ему придется подписать JWS своим каким-нибудь сертификатом — о чем мы сразу узнаем на бекенде и отклоним аттестацию.
Как я написал выше — если клиент попробует что то поменять ему придется подписать новый JWS своим сертификатом — о чем мы узнаем при проверке цепочки сертификатов и верификации сигнатуры. Это нам гарантирует что данные не претерпели изменения в процессе передачи. И нужно понимать что эта процедура изначально предусмотрена для того что бы сделать заключение о клиенте. Если он верификацию не пройдет — значит не пройдет, мы сделаем соответствующий вывод о приложении которое сейчас взаимодействует с сервером. И да в этом процессе сервер по прежнему никак не общается с Google сервисом, это и не нужно нам вполне достаточно проверить цепочку сертификатов и сигнатуру что бы понять что никто кроме гугла не подписал JWS.
Предполагается что «я» — это компания которая контролирует и серверную часть и отвечает за код запущенный на клиенте в том виде в котором он доступен из Google Play.
На том что в цепочке сертификатов нет ничего лишнего (никто не модифицировал тело JWS) — ни чьих кроме Google сертификатов. И на основании того что валидируется сигнатура с использованием корневого Google сертификата.
Тут к сожалению мне сказать нечего — это алгоритмы Google. При реализации верификации я опирался исключительно на документацию. По сути сам Google говорит что данный способ не может быть самостоятельным и полностью опираться на него при принятии решения о надежности клиента не стоит. Вы (Мы) всегда в праве придумать собственным механизм оценки клиента, кто ж мешает.
Ну частично ответил выше. А про капкан — это очень интересный вопрос) Этот вопрос стоит задать самому себе, каждому из нас, стоя в очереди в кассу за новым телефоном/планшетом/чайником.
Может и в принципе не стоит использовать этот алгоритм — придумывайте свой. Другой вопрос в стоимости решения.