Цифровой рубль в телефоне. Что говорит стандарт ЦР про мобильные приложения и при чём тут трасса вызовов?

Цифровой рубль в телефоне. Что говорит стандарт ЦР про мобильные приложения и при чём тут трасса вызовов?

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

В этой парадигме мобильное приложение, в которое участники платформы встраивают Программный модуль Банка России (ПМ БР), становится не просто интерфейсом, а ключевым звеном в этой цепочке. Именно поэтому мобильное приложение с интегрированным ПМ БР становится центральным элементом всей архитектуры платформы. Однако эта центральная роль делает мобильное приложение и самым уязвимым звеном. Здесь пересекаются требования пользовательского опыта, криптографической стойкости и регуляторного соответствия. Любое изменение в коде приложения потенциально может повлиять на работу ПМ БР, что автоматически требует дополнительных проверок со стороны надзорных органов.

Что в Стандарте?

Опубликованный «Стандарт Платформы цифрового рубля» от 20 ноября 2024 года (далее — Стандарт) чётко определяет статус мобильного приложения с интегрированным ПМ БР: он относится к средствам криптографической защиты информации. Это означает, что каждое обновление приложения формально требует прохождения процедуры оценки влияния изменений в аккредитованной лаборатории.

Но понимая, что мобильные приложения обновляются значительно чаще традиционного программного обеспечения и изменения в приложениях могут не затрагивать функционал, связанный с цифровым рублём, регулятор предусмотрел компромиссное решение: если в новой версии МП сохранились «неизменность трасс вызовов и порядка вызовов ПМ БР», то повторная оценка влияния не нужна, достаточно предоставить материалы, подтверждающие эту неизменность.

Если посмотреть детальнее, то Стандарт предъявляет к мобильным приложениям два основных требования:

1. Фиксировать и сравнивать трассы вызовов встроенного ПМ БР для каждой новой сборки.
2. Доказывать, что публичная сборка, размещённая в магазине приложений, идентична той, что была проверена в аккредитованной лаборатории.

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

Трассы вызовов, что это и как получить?

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

Для начала определим, что же такое «Трасса вызовов». По сути, это последовательность инструкций и функций, которые выполняются при обращении к Программному модулю Банка России.

Как же построить эту трассу? Это один из главных вопросов, на который ответа пока что нет, Стандарт прямо требует, чтобы «неизменность трасс вызовов и порядка вызовов ПМ БР в составе МП» подтверждалась при каждом релизе; при этом сами трассы «разрабатываются (согласовываются) совместно с испытательной лабораторией». Формально метод оставлен на усмотрение разработчика и лаборатории, поэтому практика только складывается.

На первый взгляд задача кажется простой: запусти любой популярный сканер, получи граф вызовов и сравни с эталоном. Но основная сложность построения трасс вызовов заключается в том, что современные мобильные приложения представляют собой сложные многослойные системы. Android-приложения могут содержать код одновременно на Kotlin, Java, использовать динамическую загрузку модулей. iOS-приложения сочетают Swift, Objective-C, также могут включать нативные компоненты. Ну а множество современных фреймворков с «синтаксическим сахаром» делают разработку удобнее, но анализ такого кода сильно затрудняется [1]. Классические инструменты статического анализа очень плохо справляются с задачей построения полного графа вызовов в таких сложных и разнообразных системах. Они могут проанализировать код на одном языке, но теряют связи на границах между языками, не понимают динамически создаваемые вызовы, не всегда поддерживают всё многообразие фреймворков и путаются при использовании в коде «сахара».

Что делать в том случае, когда статические анализаторы не справляются? На мой взгляд, тут на помощь приходит анализ уже скомпилированного кода. После компиляции весь «синтаксический сахар» разворачивается компилятором в стандартные конструкции, Java и Kotlin унифицируется в один формат для корректного восприятия виртуальной машиной Android, все трансграничные вещи между Objective-C и Swift имеют точную и явную связь и отображение в бинарном файле. То есть вместо запутанного, сложного и непредсказуемого кода можно использовать унифицированный и единый формат представления после компиляции.

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

Этап 1: подготовка «чистой» сборки

Первый шаг — получение приложения в форме, пригодной для анализа. Для Android это означает APK или AAB без обфускации. Для iOS требуется IPA-файл с сохранёнными dSYM-символами, содержащими отладочную информацию. Эти артефакты должны быть подписаны тем же ключом, который будет использоваться для финальной сборки, чтобы исключить возможность подмены.

Этап 2: построение ориентированного графа

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

Этап 3: фильтрация и выделение трасс ПМ БР

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

Этап 4: сравнение с эталоном

Финальный этап — сравнение полученных трасс с эталонными, зафиксированными при первичной экспертизе. Алгоритм сравнения ищет структурные различия: добавленные или удалённые вершины, изменившиеся связи, новые пути вызовов. Любые изменения, затрагивающие цепочки, ведущие к ПМ БР, классифицируются как «критичные» и требуют дополнительного анализа.

В результате мы получаем гарантированно повторяемый и стабильный результат по составлению и контролю трассы вызовов, который подсвечивает любые изменения или новые трассы до методов ПМ БР, что полностью соответствует описанным требованиям в Стандарте.

Доказательство идентичности сборок

Но остаётся ещё один вопрос: как доказать, что приложение, которое передаётся на анализ в испытательную лабораторию, соответствует тому, что выкладывается в магазины приложений?

Казалось бы, сравни два файла, посчитай хеш-суммы и убедись в идентичности. Но как оказывается, это совсем не тривиальная задача, так как при сборке даже из одного и того же кода приложение будет иметь разные хеш-суммы по разным причинам. Это и различные создаваемые во время сборки файлы, и уникальные для каждой сборки идентификаторы (рекламные, аналитические и другие). Более того, магазины приложений сами вносят изменения в приложения. Например, Google Play с 2021 года требует загрузки приложений в формате AAB (Android App Bundle), который затем автоматически разделяется на device-специфичные пакеты и переподписывается ключами, сгенерированными на стороне Google. Apple же применяет к приложениям FairPlay-шифрование, которое кардинально изменяет структуру исполняемого файла. В результате контрольная сумма приложения в магазине никогда не совпадает с контрольной суммой исходной сборки. А если разработчик приложения применяет усиленные меры шифрования для своих сборок — это отдельная история.

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

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

Организационная составляющая решения требует строгого контроля доступа к релизным ключам и переменным сборочного конвейера. Все операции должны выполняться автоматически и только в CI/CD-системе, исключая возможность ручного вмешательства. Перечень лиц, имеющих доступ к критически важным компонентам, должен быть документально зафиксирован и ограничен техническими средствами. Такое решение позволяет владельцу ПО скачать приложение из магазина, извлечь из него метаданные происхождения и сопоставить их с данными из лабораторного протокола. Организационные меры обеспечивают, что эти метаданные не могли быть подделаны благодаря защищённому процессу сборки и ограниченному доступу к ключам подписи.

Заключение

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

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

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

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

[1] Синтаксический сахар в программировании — упрощённые формы записи конструкций языка, которые не меняют логику работы программы, но делают код более читаемым и удобным для написания. Это своего рода «дополнительные возможности» в синтаксисе, которые позволяют выражать те же идеи более лаконично и понятно для разработчика.