Почему шифрование моделей на устройстве не может заменить авторизацию через API

Декомпозиция мобильных AI-приложений на семь классов активов

Безопасность мобильных AI-приложений часто упрощается до вопроса наличия шифрования модели. В действительности поверхность атаки включает как минимум файлы моделей, среды выполнения вывода, предварительную обработку входных данных, постобработку выходных данных, промпты или бизнес-правила, учетные данные удаленного API, пользовательские данные и логи. Каждый класс активов несет различные последствия при утечке, имеет отличные механизмы обновления и отдельные зоны ответственности.

Копирование весов модели может привести к краже интеллектуальной собственности и потере бизнес-возможностей; изменение шаблонов промптов или логики постобработки может исказить бизнес-поведение; утечка долгоживущих ключей API может напрямую привести к финансовым потерям, несанкционированному доступу к данным или злоупотреблению ресурсами; логи ввода/вывода могут содержать конфиденциальные пользовательские данные. Защита только файла модели не покрывает эти остающиеся риски.

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

Файлы моделей должны становиться рабочим материалом во время выполнения

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

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

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

Долгосрочные API-ключи с высокими привилегиями не должны быть клиентскими секретами

Документация по безопасности Android прямо указывает, что API-ключи, внедренные в исходный код, могут быть обнаружены посредством дизассемблирования после компиляции приложения. Обфускация и упрочнение приложения (application hardening) могут повысить затраты на их поиск, но не изменят тот факт, что клиент должен хранить и использовать эти учетные данные. Пока ключ остается долгосрочным и высокопривилегированным в универсальном клиенте, последствия его утечки трудно ограничить.

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

Более надежная архитектура требует, чтобы клиент запрашивал у своего сервиса краткосрочные, ограниченные и отзываемые токены на основе идентичности пользователя и контекста устройства, либо чтобы серверный прокси обрабатывал вызовы функций (function invocation) моделей с высоким риском. Сервер должен обеспечивать авторизацию учетной записи, квоты, ограничение частоты запросов, область действия модели, область данных и мониторинг аномального поведения.

• Изолировать учетные данные по средам разработки, тестирования и промышленной эксплуатации
• Гарантировать, что токены обладают минимальными правами доступа к моделям и данным
• Включить отзыв на стороне сервера и обеспечить соблюдение квот и ограничений частоты запросов
• Предотвратить хранение клиентами долгосрочных общих ключей с высокими привилегиями

request = verify_user_session(input.session)
app = verify_app_evidence(input.attestation)
policy = load_policy(user=request.user, app=app.identity)

if policy.version_state == UNKNOWN:
    return CHALLENGE_OR_LIMIT
if policy.account_scope.allows(input.model_scope) == false:
    return DENY
if policy.risk_score >= HIGH:
    return STEP_UP_VERIFICATION

return issue_short_lived_token(
    scope=input.model_scope,
    quota=policy.quota,
    expires_in=policy.short_window
)

Сигналы целостности должны использоваться только для принятия решений на стороне сервера

Play Integrity предоставляет бэкендам Android сигналы об идентификации приложения, целостности устройства, лицензировании аккаунта и частичных рисках окружения. Apple App Attest помогает серверу определить, исходит ли запрос от валидного экземпляра приложения, генерируя ключи устройства, выдавая одноразовые челленджи, проверяя аттестацию на сервере и обрабатывая последующие утверждения. Общим является то, что доказательства в конечном итоге проверяются сервером.

Эти механизмы имеют четкие границы. Сигналы Play зависят от источников дистрибуции, статуса устройства и условий работы сервисов; документация Apple указывает, что App Attest поддерживается не на всех типах устройств и ни одна политика не устраняет мошенничество полностью. Сервер должен различать состояния успеха, неудачи, недоступности, временных ошибок и несконфигурированности. Он не должен приравнивать «недоступность» напрямую к атаке и не должен выполнять окончательные суждения локально на клиенте.

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

Валидация мобильных AI-приложений требует статического, рантайм и серверного взгляда

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

Тестирование должно использовать уникальные release candidate и явные версии моделей, документируя целевые системы, возможности устройств, рантайм-бэкенды, источники моделей и состояния обновлений. Производительность инференса on-device, использование памяти и совместимость зависят от структуры модели, квантования, аппаратного обеспечения и рантайма; цифры от других моделей или устройств цитировать нельзя.

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

Выводы по архитектуре и ограничения области применения

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

Без актуальных кандидатов на выпуск (release candidates), версий моделей, целевых устройств и серверных интерфейсов возможна только проверка архитектуры и ожидание результатов валидации. Мы не можем утверждать, что модели защищены от извлечения, интерфейсы устойчивы к злоупотреблениям, внедрение кода во время выполнения заблокировано или целевые показатели производительности достигнуты. Любые такие выводы требуют предоставления актуальных пакетов доказательств.

Точка входа для услуг Yudun на этой странице предназначена для подачи заявки на упрочнение приложений (application hardening) и оценку совместимости; она не означает валидацию какого-либо конкретного фреймворка моделей или возможностей, эксклюзивных для ИИ. Область проекта должна быть подтверждена отдельно после предоставления стека технологий, способа доставки модели и критических бизнес-сценариев.

• Вести раздельные реестры для моделей, сред выполнения, учетных данных и данных
• Обеспечить финальную авторизацию вызовов высокого риска на стороне сервера
• Предусмотреть пути обработки недоступности и деградации функциональности для сигналов платформы
• Реализовать поддержку обновлений моделей с возможностью верификации, атомарного переключения и отката
• Привязать все выводы к конкретным кандидатам на выпуск и версиям моделей