Carding 4 Carders
Professional
- Messages
- 2,724
- Reaction score
- 1,586
- Points
- 113
Коммодитизация безопасности
С момента появления первых смартфонов в начале 2000-х годов многое изменилось. Теперь мы интегрируем многие из наших повседневных потребностей в эти уникальные устройства. Наши коммуникации, наши календари, наши фотографии, все наши социальные взаимодействия обычно фиксируются в этих системах или управляются через них. Все чаще мы добавляем к этим личным аспектам больше деловых и коммерческих функций; платежи, билеты, документы, удостоверяющие личность, даже используя их для управления магазином, функции киоска или в качестве человеко-машинного интерфейса для множества других устройств и систем.
Таким образом, системы, которые управляют нашими данными и взаимодействуют с ними, были централизованы и даже превращены в товар на этих мобильных устройствах. Устройства, которые изначально не предназначались для таких целей.
Это хорошо или плохо?
В серии блогов мы расскажем, как можно использовать эти системы, как их можно защитить и какие уникальные аспекты они имеют, на что важно обратить особое внимание. В этом конкретном блоге мы конкретно обсуждаем аспекты безопасности мобильных устройств на базе Android. Мы доверяем им так много своей информации, но как мы можем быть уверены, что эта информация надежно защищена? Как разработчик или разработчик приложений или систем, использующих приложения, может скомпрометировать безопасность этих систем и как лучше всего защититься от таких угроз?
Это не так плохо, как вы думаете
Хорошая новость заключается в том, что многие из используемых сегодня мобильных / планшетных систем можно считать одними из самых безопасных устройств потребительского уровня, которые когда-либо были доступны. Они объединяют множество функций, специально разработанных для защиты данных и приложений, которые на них выполняются - обязательные элементы управления доступом, рандомизация адресного пространства, доверенные среды выполнения и встроенные элементы безопасности, элементы управления аутентификацией указателя и биты без выполнения… список можно продолжить.
Поэтому, хотя часто есть много комментариев о последних уязвимостях или проблемах приложений для мобильных / планшетных устройств, большая часть из них в лучшем случае плохо интерпретируется, чтобы указать, что все такие устройства небезопасны, и это просто неправильно. «Безопасность» как концепция требует понимания того, что вы пытаетесь защитить и какой уровень защиты требуется, и для подавляющего большинства пользователей мобильные и планшетные устройства, которые они используют, могут считаться «безопасными» для их целей - если они обновляются с помощью исправлений, и правильно ли реализованы средства управления, которые они обеспечивают для обеспечения безопасности.
Компания Gartner недавно выпустила документ, в котором сравниваются многие основные операционные системы с точки зрения безопасности, и фактически благодаря этому они пришли к выводу, что последняя версия Android с исправлениями является одной из самых безопасных систем, которые вы можете использовать (название самый безопасный достался Chrome OS). Конечно, есть аргументы в пользу используемой здесь методологии - она не учитывает некоторые архитектурные аспекты, такие как аутентификация указателя, используемая в более поздних системах iOS, и область применения очень специфична для Android (охватывает только реализации на Google Pixel), но это говорит о том, что мобильная безопасность действительно прошла долгий путь.
Этот блог не предназначен для освещения всех деталей элементов управления, реализованных в каждой мобильной операционной системе - если вам интересно, у Google есть отличный документ для Android и Apple, что-то похожее для их собственных устройств iOS - вместо этого посмотрите на детали реализации эти элементы управления, что может пойти не так и как предотвратить это как разработчик или пользователь таких приложений.
Хорошо, может быть, это так плохо, как ты думаешь
К сожалению, часто встречаются ошибки реализации и непонимание элементов управления, предоставляемых этими платформами. Эти проблемы могут усугубляться отсутствием обновленных систем, существующих на местах - для систем Android, не производимых напрямую Google (то есть линейка телефонов Pixel), часто возникают задержки с выпуском исправлений или обновлений ОС. Со временем ситуация стала лучше: Google решает эти проблемы напрямую с помощью своего «проекта Treble» в Android 8, продолжающееся разделение важных функций на компоненты, которые Google может обновлять напрямую (через такие проекты, как «mainline»), и создание новых способов. для обновления компонентов, которые (по разным причинам) остались не исправленными. Теперь Google специально призывает устройства, которые реализованы для получения более регулярных обновлений в их программах Android One и Android Enterprise Recommended .
Однако будет просто правильно сказать, что многие мобильные / планшетные системы имеют постоянную проблему со своевременными обновлениями. Проблема в том, что эти системы представляют собой очень большую и очень интересную цель для исследований и разработок в области безопасности. Поскольку мы продолжаем развивать саму науку о безопасности, поскольку мы продолжаем обнаруживать совершенно новые типы уязвимостей , невозможно, чтобы какая-либо система считалась `` безопасной '' в течение длительного периода времени, не обеспечив при этом исправления для этих новых типов. атак.
Помимо самих операционных систем, эти системы, возможно, легче определить по приложениям, которые на них выполняются. Хотя некоторые из первоначальных планов для смартфонов, как известно, не включали магазины приложений, сегодня они являются неотъемлемой частью любого такого устройства. Это привело к появлению на распространенных платформах миллионов приложений, каждое из которых представляет собой потенциально опасную программу, ожидающую выполнения на устройстве пользователя.
Приложения по умолчанию / чрезмерные разрешения
Возможно, одна из основных проблем безопасности Android - это количество и тип приложений, которые по умолчанию загружаются в некоторые мобильные системы, так называемое «раздутое ПО», которое может иметь повышенные разрешения или проблемы с безопасностью. Это не столько проблема с устройствами Pixel, приобретенными непосредственно у Google, или устройствами iOS, где ОС строго контролируется одним поставщиком продукта, но это определенно проблема для многих устройств Android, продаваемых по всему миру (с этой проблемой быть более выраженным в одних регионах, чем в других).
Именно эти приложения по умолчанию - приложения, которые пользователь не имеет права голоса в своем присутствии на устройстве, которое они используют, - часто подвергают наибольшему риску . Помимо приложений, каждый поставщик мобильной системы и оператор мобильной сети могут в большей или меньшей степени манипулировать базовой операционной системой; добавление собственного магазина приложений, собственных настроек графического интерфейса, собственных приложений и драйверов, и любое из них также может привести к проблемам с безопасностью.
Многие приложения по умолчанию предоставляются с «системными» привилегиями или выполняются под идентификатором пользователя поставщика платформы, что дает им дополнительные функции, которые обычно не предоставляются или недоступны приложениям, загружаемым пользователем. Это означает, что любая проблема безопасности, которая очевидна в этих приложениях, может привести к большему уровню компрометации устройства.
В качестве поставщиков или распространителей мобильных систем настоятельно рекомендуется не вносить изменения в разрешения приложений Android по умолчанию и сводить к минимуму любые дополнительные приложения, загружаемые в систему по умолчанию. Кроме того, убедитесь, что любые дополнительные приложения или драйверы обновляются безопасным способом.
Конфигурация устройства и устаревшие проблемы
Современные операционные системы сложны, и широта их реализаций безопасности часто может сделать создание специальной версии или установку этой операционной системы еще более сложной. Когда поставщик поставляет новое устройство Android, оно имеет множество различных аппаратных интерфейсов, которые должны абстрагироваться с помощью уровня аппаратной абстракции (HAL), есть много различных элементов пользовательского интерфейса, которые поставщик может захотеть настроить, и есть новые функции, которые поставщик могут захотеть добавить, чтобы дифференцировать свое решение.
Вся эта настройка часто может нарушать функции безопасности, лежащие в основе операционной системы Android, и это может привести к отключению или изменению функций, которые в противном случае были бы оставлены в более безопасном состоянии. Поставщики платформ Android должны быть очень осторожны, чтобы повторно включить любые такие отключенные функции или удалить отладку и другие функции до отправки готовой системы.
Технический долг / исторические API
Проблема, с которой сталкиваются все вычислительные системы, все реализации вычислительных систем, - это проблема технического долга. Поскольку безопасность - это подвижная цель, и поскольку мы постоянно повышаем безопасность наших операционных систем и вычислительных платформ, приложения и интерфейсы, которые они используют, имеют тенденцию «стареть». Невозможно `` отключить '' старые API-интерфейсы или приложения просто потому, что они, как было установлено, обеспечивают или облегчают небезопасность платформы - это мгновенно сделает все существующие системы, использующие их, неработоспособными - поэтому должна быть некоторая задержка между включением повышенная безопасность и отключение старых систем, которым не хватает этого уровня безопасности.
Это приводит к техническому долгу. Мы видим это в исторической поддержке старых приложений в операционных системах для настольных ПК, но, возможно, это более заметно в мобильных системах, полностью потому, что их уровни безопасности продолжают стремительно расти. Например, в каждой новой версии мобильной операционной системы обычно добавляются функции безопасности и накладываются ограничения на использование того, что ранее считалось чрезмерно разрешающим API, но остается необходимость в поддержке и старых приложений. .
На момент написания статьи Android требует, чтобы любое приложение, представленное в Play Store, должно поддерживать уровень API 28, что соответствует Android 9. Однако могут поддерживаться и более низкие уровни API, которые могут быть установлены как минимальные, если приложение загружено. другими способами (такими как «боковая загрузка» или использование стороннего магазина приложений). Это может позволить приложениям обходить функции безопасности, которые в противном случае встроены в операционную систему - например, загрузка приложения Android из-за пределов Google Play Store может позволить использовать устаревшие API специальных возможностей, которые фиксируют события касания пользователя или обеспечивают другие неприемлемые уровни. доступа, который ранее был запрещен.
Минимальные требования
По мере того, как каждая версия операционной системы становится более безопасной, поэтому выполнение минимальных требований для устройств, поставляемых с этой версией операционной системы … вроде как. Некоторые из минимальных требований применимы только к тем устройствам, которые проходят первоначальное тестирование совместимости с Android с этой версией; любые устройства, которые были обновлены до новой версии операционной системы после этого первоначального тестирования, могут не соответствовать минимальным требованиям или не соответствовать им.
Это, конечно, имеет смысл, поскольку вы не хотите ограничивать развертывание большинства новых функций, предоставляемых обновлением операционной системы, из-за некоторых небольших ограничений на существующее оборудование. Однако это также означает, что как разработчик приложения вы не всегда можете полагаться на однозначное сопоставление версии операционной системы с минимальными требованиями к оборудованию, а поскольку некоторые аппаратные функции являются обязательными даже для обновлений, не всегда бывает так, что каждое устройство будет иметь возможность обновляться с новой ОС.
Предоставление пользовательских приложений
Конечно, как уже отмечалось, технический долг является проблемой и для компьютеров общего назначения - возможно, в большей степени, поскольку у них более длительная история программ и систем, которые они должны поддерживать, что привело к общему отсутствию успеха для `` магазина ''. 'модель распространения, которая обычно используется на мобильной арене.
Возможность простого и безопасного доступа к огромному спектру приложений через «магазин» ОС, безусловно, является одним из величайших преимуществ мобильных операционных систем, но это также проблема, когда мы пытаемся использовать такие приложения для замены сделанных на заказ системы прежде всего потому, что каждое «приложение» всегда должно запускаться одинаково при первой загрузке. Однако обычно возникает необходимость персонализировать это приложение с помощью конкретных данных для телефона и / или пользователя, обычно получаемых через серверный хост.
Эта стадия персонализации проблематична, потому что очень сложно, а возможно, и невозможно аутентифицировать приложение как подлинное при самом первом запуске и подключении к серверным системам. Общие решения, как правило, используют встроенные секреты (защищенные с помощью криптографии «белого ящика») или удаленные системы «аттестации» для аутентификации экземпляра приложения.
Хранение данных в телефоне
После того, как устройство «подготовлено» и используется, подразумевается, что в этом приложении должны храниться некоторые уникальные данные. Это могут быть уникальные идентификаторы, более сложные структуры данных или уникальные криптографические ключи для конкретных приложений, которые должны быть сгенерированы и сохранены на устройстве. Существует множество вариантов безопасного хранения этих значений на мобильном устройстве, от простых разрешений на уровне файловой системы до защиты в отдельных аппаратных компонентах на устройстве.
Самый простой метод контроля доступа - использование файловой системы устройства. Здесь необходимо позаботиться о том, чтобы были применены правильные разрешения доступа, чтобы файл не был доступен для чтения, установив файл как «зависящий от приложения». Важно отметить, что даже после этого все приложения, подписанные одним и тем же ключом разработчика, выполняются от имени одного и того же пользователя и, следовательно, смогут получить доступ к любым файлам, даже если права доступа ограничены.
Начиная с Android 7 появилась возможность применять шифрование на основе файлов (FBE), которое шифрует файлы в хранилище на основе учетных данных пользователя - так что, если устройство является многопользовательским или имеет несколько профилей пользователей, доступ к приложения и файлы для этих приложений могут быть ограничены определенной учетной записью или пользователем.
Файлы, расположенные на внешнем хранилище, легко извлекаются и читаются. Более поздние версии Android позволяют «использовать» съемные носители со встроенным хранилищем и использовать шифрование для защиты этих носителей. Однако только после того, как Android 9 «адаптировал» съемные носители, работал с FBE, и по этой причине (а также по другим причинам, таким как надежность и скорость) использование внешнего хранилища для безопасных файлов, как правило, не рекомендуется.
В самом деле, обычно не считается достаточным разрешить только использование безопасности файловой системы для защиты конфиденциальной информации в приложении, и поэтому настоятельно рекомендуется использовать дополнительные механизмы защиты - чаще всего шифрование на основе приложений. Однако этот тип защиты вызывает затруднения; Хотя само шифрование может использоваться для предотвращения прямого «чтения» содержимого файла, обеспечиваемая безопасность настолько сильна, насколько надежна защита, применяемая к используемому криптографическому ключу.
К счастью, Android изначально предоставляет методы для генерации и использования ключей для шифрования файлов, так что приложениям не нужно напрямую обращаться к этим ключам или использовать их.
Хранение ключей и безопасность
Следовательно, использование шифрования для защиты данных можно рассматривать как перенос сложности защиты от файла (ов) или самих элементов данных до ключа (ов). Хорошая новость заключается в том, что, поскольку криптографические ключи намного меньше, чем большинство файлов (часто намного меньше 1 КБ), их несколько легче надежно хранить. Android предоставляет ряд конкретных методов хранения для защиты криптографических ключей, которые могут использоваться приложениями для прямого шифрования данных как для хранения, так и для транспортировки, как показано ниже.
Защита криптографических ключей в системах COTS может включать как программные, так и аппаратные методы.
Метод хранения, который вы используете, будет зависеть от желаемого уровня безопасности, сбалансированного с учетом соображений совместимости. Только программные методы, такие как криптография Whitebox или программные TEE, являются наиболее широко используемыми для множества устройств, но также обеспечивают базовый уровень безопасности по сравнению с другими вариантами. Существует множество научных статей, в которых обсуждаются атаки (и меры по их устранению) на криптографические системы Whitebox, и часто возможны такие атаки, как дифференциальные вычислительные побочные каналы и внедрение ошибок.
Аппаратные TEE и программные анклавы, которые используют аппаратные функции для разделения областей памяти (в идеале с использованием шифрования, а также других функций изоляции памяти), обеспечивают повышенный уровень разделения, гарантируя, что операции и данные, которыми управляют в этих средах, защищены от доступа систем, выполняющих в Rich Execution Environment. Однако в этих системах также возможны атаки по побочному каналу и RCE .
Из-за этих типов атак хранение криптографических ключей часто лучше всего реализовать в полностью отдельном кристалле - с использованием скрытого «чипа», такого как встроенный процессор Secure Element или Secure Enclave. Устройства с Android 9 и выше поддерживают использование такой встроенной аппаратной системы хранения данных, называемой «Strongbox», а требования утверждения Common Criteria для EAL 5+ на таких микросхемах внутренней безопасности обеспечивают очень высокий уровень гарантии безопасности. .
Конечно, прежде чем хранить ключ, вы должны иметь ключ для хранения! Создание, ввод, дешифрование или согласование ключей в мобильных системах может иметь свои собственные проблемы - некоторые стандарты (например, PCI CPoC) требуют, по крайней мере, получения исходных данных энтропии из внешних входов, таких как серверный HSM, подключенный ключ или другой пользователь. входы и датчики устройства, помогающие генерировать случайные данные.
Однако у таких датчиков могут быть свои проблемы ...
Использование данных датчиков
В предыдущем разделе мы упоминали атаки по побочным каналам, поскольку они применяются к извлечению или определению хранимых секретов, таких как криптографические ключи. Однако атаки по побочному каналу также могут применяться для восстановления данных по мере их ввода в устройство - посредством мониторинга светового датчика, акселерометра и гироскопа , даже сигнала Wi-Fi.
Мониторинг ввода ПИН-кода пользователя с помощью акселерометра
Защита от такого рода утечек во время работы затруднена без усиления защиты со стороны операционной системы для отключения использования фонового датчика. Однако важно понимать, что такие атаки возможны, чтобы вы могли встроить их в свои модели угроз по мере разработки решений.
Транспортная безопасность
Одна из самых простых вещей, которую вы можете сделать для защиты своего приложения, - это убедиться, что соединение, которое оно устанавливает с серверными системами, защищено с помощью TLS. Android делает это относительно легко, но вы должны помнить, что TLS - это набор протоколов и методов подключения, и не все из них будут обеспечивать необходимую безопасность. Если аутентичность вашего бэкэнда важна, всегда проверяйте сертификат, предоставленный этим бэкэндом (в процессе, называемом «закрепление сертификата»), чтобы убедиться, что вы не просто разговариваете с каким-либо хостом TLS - вы разговариваете с хостом, на котором вы фактически хочу поговорить!
Не менее важным, чем принятый вами сертификат, является «набор шифров», который вы используете для защиты соединения после его установления. Это выбирается на основе общих реализаций, поддерживаемых сервером и клиентским приложением (на мобильном устройстве), подчеркивая, что не только мобильное приложение влияет на безопасность любой реализации - то, как вы настраиваете любые серверные системы, также жизненно важно. .
Для реализаций с высоким уровнем безопасности вы можете рассмотреть возможность дополнительного шифрования конфиденциальных данных помимо защиты, обеспечиваемой самим TLS-соединением. Это может помочь изолировать эти данные от уязвимости в бэкэнд-системах, где соединения TLS обычно завершаются на границе сети, а также реализовать общую `` глубокую защиту '', чтобы снизить риск раскрытия, если есть проблема, вызванная раскрытием данные сертификата или обнаружена новая уязвимость в TLS.
Конфиденциальность против систем аттестации
По мере того, как мы расширяем использование систем COTS для использования в различных сферах деятельности и с различной конфиденциальной информацией, «системы аттестации» становятся все более популярными. Эти системы собирают данные с платформы и передают их в среду удаленной обработки для анализа, что позволяет сравнивать эти данные с аналогичными данными из многих других систем или проверять криптографически на основе надежно хранимого закрытого ключа.
Google реализует собственную систему аттестации, известную как SafetyNet. Это помогает предоставить информацию о базовой платформе и самом приложении в отношении того, считается ли это высоким риском. Однако Google особо отмечает, что эту систему не следует использовать в качестве единственного метода защиты или аттестации для приложения - это компонент решения, которое вам необходимо создать самостоятельно.
Safetynet также может разрешить «аттестацию ключа» обратно в сервисы Google. Это можно использовать как для проверки безопасности ключей, сгенерированных и хранимых на этом устройстве, так и для подтверждения того, что телефон является подлинным устройством Android, а не эмулятором, и имеет неповрежденную цепочку доверия для процесса загрузки. Совсем недавно Google, кажется, внедряет обновления для этого, которые могут сделать его более полезным для обнаружения «рутированных» телефонов, что хорошо для безопасности.
Что такое хорошая безопасность?
Безопасность - понятие относительное. То, что может считаться «безопасным» для одного использования, может быть небезопасным для другого варианта использования. При создании приложений для Android у Google есть хорошее руководство по вопросам, которые следует учитывать в отношении общей безопасности. Если вы создаете приложения, которые имеют более строгие требования к безопасности, чем «нормальное» приложение, вы можете также рассмотреть возможность выхода за рамки этого руководства.
Взгляды и мнения, выраженные в этой статье, не обязательно отражают официальную позицию.
С момента появления первых смартфонов в начале 2000-х годов многое изменилось. Теперь мы интегрируем многие из наших повседневных потребностей в эти уникальные устройства. Наши коммуникации, наши календари, наши фотографии, все наши социальные взаимодействия обычно фиксируются в этих системах или управляются через них. Все чаще мы добавляем к этим личным аспектам больше деловых и коммерческих функций; платежи, билеты, документы, удостоверяющие личность, даже используя их для управления магазином, функции киоска или в качестве человеко-машинного интерфейса для множества других устройств и систем.
Таким образом, системы, которые управляют нашими данными и взаимодействуют с ними, были централизованы и даже превращены в товар на этих мобильных устройствах. Устройства, которые изначально не предназначались для таких целей.
Это хорошо или плохо?
В серии блогов мы расскажем, как можно использовать эти системы, как их можно защитить и какие уникальные аспекты они имеют, на что важно обратить особое внимание. В этом конкретном блоге мы конкретно обсуждаем аспекты безопасности мобильных устройств на базе Android. Мы доверяем им так много своей информации, но как мы можем быть уверены, что эта информация надежно защищена? Как разработчик или разработчик приложений или систем, использующих приложения, может скомпрометировать безопасность этих систем и как лучше всего защититься от таких угроз?
Это не так плохо, как вы думаете
Хорошая новость заключается в том, что многие из используемых сегодня мобильных / планшетных систем можно считать одними из самых безопасных устройств потребительского уровня, которые когда-либо были доступны. Они объединяют множество функций, специально разработанных для защиты данных и приложений, которые на них выполняются - обязательные элементы управления доступом, рандомизация адресного пространства, доверенные среды выполнения и встроенные элементы безопасности, элементы управления аутентификацией указателя и биты без выполнения… список можно продолжить.
Поэтому, хотя часто есть много комментариев о последних уязвимостях или проблемах приложений для мобильных / планшетных устройств, большая часть из них в лучшем случае плохо интерпретируется, чтобы указать, что все такие устройства небезопасны, и это просто неправильно. «Безопасность» как концепция требует понимания того, что вы пытаетесь защитить и какой уровень защиты требуется, и для подавляющего большинства пользователей мобильные и планшетные устройства, которые они используют, могут считаться «безопасными» для их целей - если они обновляются с помощью исправлений, и правильно ли реализованы средства управления, которые они обеспечивают для обеспечения безопасности.
Компания Gartner недавно выпустила документ, в котором сравниваются многие основные операционные системы с точки зрения безопасности, и фактически благодаря этому они пришли к выводу, что последняя версия Android с исправлениями является одной из самых безопасных систем, которые вы можете использовать (название самый безопасный достался Chrome OS). Конечно, есть аргументы в пользу используемой здесь методологии - она не учитывает некоторые архитектурные аспекты, такие как аутентификация указателя, используемая в более поздних системах iOS, и область применения очень специфична для Android (охватывает только реализации на Google Pixel), но это говорит о том, что мобильная безопасность действительно прошла долгий путь.
Этот блог не предназначен для освещения всех деталей элементов управления, реализованных в каждой мобильной операционной системе - если вам интересно, у Google есть отличный документ для Android и Apple, что-то похожее для их собственных устройств iOS - вместо этого посмотрите на детали реализации эти элементы управления, что может пойти не так и как предотвратить это как разработчик или пользователь таких приложений.
Хорошо, может быть, это так плохо, как ты думаешь
К сожалению, часто встречаются ошибки реализации и непонимание элементов управления, предоставляемых этими платформами. Эти проблемы могут усугубляться отсутствием обновленных систем, существующих на местах - для систем Android, не производимых напрямую Google (то есть линейка телефонов Pixel), часто возникают задержки с выпуском исправлений или обновлений ОС. Со временем ситуация стала лучше: Google решает эти проблемы напрямую с помощью своего «проекта Treble» в Android 8, продолжающееся разделение важных функций на компоненты, которые Google может обновлять напрямую (через такие проекты, как «mainline»), и создание новых способов. для обновления компонентов, которые (по разным причинам) остались не исправленными. Теперь Google специально призывает устройства, которые реализованы для получения более регулярных обновлений в их программах Android One и Android Enterprise Recommended .
Однако будет просто правильно сказать, что многие мобильные / планшетные системы имеют постоянную проблему со своевременными обновлениями. Проблема в том, что эти системы представляют собой очень большую и очень интересную цель для исследований и разработок в области безопасности. Поскольку мы продолжаем развивать саму науку о безопасности, поскольку мы продолжаем обнаруживать совершенно новые типы уязвимостей , невозможно, чтобы какая-либо система считалась `` безопасной '' в течение длительного периода времени, не обеспечив при этом исправления для этих новых типов. атак.
Помимо самих операционных систем, эти системы, возможно, легче определить по приложениям, которые на них выполняются. Хотя некоторые из первоначальных планов для смартфонов, как известно, не включали магазины приложений, сегодня они являются неотъемлемой частью любого такого устройства. Это привело к появлению на распространенных платформах миллионов приложений, каждое из которых представляет собой потенциально опасную программу, ожидающую выполнения на устройстве пользователя.
Приложения по умолчанию / чрезмерные разрешения
Возможно, одна из основных проблем безопасности Android - это количество и тип приложений, которые по умолчанию загружаются в некоторые мобильные системы, так называемое «раздутое ПО», которое может иметь повышенные разрешения или проблемы с безопасностью. Это не столько проблема с устройствами Pixel, приобретенными непосредственно у Google, или устройствами iOS, где ОС строго контролируется одним поставщиком продукта, но это определенно проблема для многих устройств Android, продаваемых по всему миру (с этой проблемой быть более выраженным в одних регионах, чем в других).
Именно эти приложения по умолчанию - приложения, которые пользователь не имеет права голоса в своем присутствии на устройстве, которое они используют, - часто подвергают наибольшему риску . Помимо приложений, каждый поставщик мобильной системы и оператор мобильной сети могут в большей или меньшей степени манипулировать базовой операционной системой; добавление собственного магазина приложений, собственных настроек графического интерфейса, собственных приложений и драйверов, и любое из них также может привести к проблемам с безопасностью.
Многие приложения по умолчанию предоставляются с «системными» привилегиями или выполняются под идентификатором пользователя поставщика платформы, что дает им дополнительные функции, которые обычно не предоставляются или недоступны приложениям, загружаемым пользователем. Это означает, что любая проблема безопасности, которая очевидна в этих приложениях, может привести к большему уровню компрометации устройства.
В качестве поставщиков или распространителей мобильных систем настоятельно рекомендуется не вносить изменения в разрешения приложений Android по умолчанию и сводить к минимуму любые дополнительные приложения, загружаемые в систему по умолчанию. Кроме того, убедитесь, что любые дополнительные приложения или драйверы обновляются безопасным способом.
Конфигурация устройства и устаревшие проблемы
Современные операционные системы сложны, и широта их реализаций безопасности часто может сделать создание специальной версии или установку этой операционной системы еще более сложной. Когда поставщик поставляет новое устройство Android, оно имеет множество различных аппаратных интерфейсов, которые должны абстрагироваться с помощью уровня аппаратной абстракции (HAL), есть много различных элементов пользовательского интерфейса, которые поставщик может захотеть настроить, и есть новые функции, которые поставщик могут захотеть добавить, чтобы дифференцировать свое решение.
Вся эта настройка часто может нарушать функции безопасности, лежащие в основе операционной системы Android, и это может привести к отключению или изменению функций, которые в противном случае были бы оставлены в более безопасном состоянии. Поставщики платформ Android должны быть очень осторожны, чтобы повторно включить любые такие отключенные функции или удалить отладку и другие функции до отправки готовой системы.
Технический долг / исторические API
Проблема, с которой сталкиваются все вычислительные системы, все реализации вычислительных систем, - это проблема технического долга. Поскольку безопасность - это подвижная цель, и поскольку мы постоянно повышаем безопасность наших операционных систем и вычислительных платформ, приложения и интерфейсы, которые они используют, имеют тенденцию «стареть». Невозможно `` отключить '' старые API-интерфейсы или приложения просто потому, что они, как было установлено, обеспечивают или облегчают небезопасность платформы - это мгновенно сделает все существующие системы, использующие их, неработоспособными - поэтому должна быть некоторая задержка между включением повышенная безопасность и отключение старых систем, которым не хватает этого уровня безопасности.
Это приводит к техническому долгу. Мы видим это в исторической поддержке старых приложений в операционных системах для настольных ПК, но, возможно, это более заметно в мобильных системах, полностью потому, что их уровни безопасности продолжают стремительно расти. Например, в каждой новой версии мобильной операционной системы обычно добавляются функции безопасности и накладываются ограничения на использование того, что ранее считалось чрезмерно разрешающим API, но остается необходимость в поддержке и старых приложений. .
На момент написания статьи Android требует, чтобы любое приложение, представленное в Play Store, должно поддерживать уровень API 28, что соответствует Android 9. Однако могут поддерживаться и более низкие уровни API, которые могут быть установлены как минимальные, если приложение загружено. другими способами (такими как «боковая загрузка» или использование стороннего магазина приложений). Это может позволить приложениям обходить функции безопасности, которые в противном случае встроены в операционную систему - например, загрузка приложения Android из-за пределов Google Play Store может позволить использовать устаревшие API специальных возможностей, которые фиксируют события касания пользователя или обеспечивают другие неприемлемые уровни. доступа, который ранее был запрещен.
Минимальные требования
По мере того, как каждая версия операционной системы становится более безопасной, поэтому выполнение минимальных требований для устройств, поставляемых с этой версией операционной системы … вроде как. Некоторые из минимальных требований применимы только к тем устройствам, которые проходят первоначальное тестирование совместимости с Android с этой версией; любые устройства, которые были обновлены до новой версии операционной системы после этого первоначального тестирования, могут не соответствовать минимальным требованиям или не соответствовать им.
Это, конечно, имеет смысл, поскольку вы не хотите ограничивать развертывание большинства новых функций, предоставляемых обновлением операционной системы, из-за некоторых небольших ограничений на существующее оборудование. Однако это также означает, что как разработчик приложения вы не всегда можете полагаться на однозначное сопоставление версии операционной системы с минимальными требованиями к оборудованию, а поскольку некоторые аппаратные функции являются обязательными даже для обновлений, не всегда бывает так, что каждое устройство будет иметь возможность обновляться с новой ОС.
Предоставление пользовательских приложений
Конечно, как уже отмечалось, технический долг является проблемой и для компьютеров общего назначения - возможно, в большей степени, поскольку у них более длительная история программ и систем, которые они должны поддерживать, что привело к общему отсутствию успеха для `` магазина ''. 'модель распространения, которая обычно используется на мобильной арене.
Возможность простого и безопасного доступа к огромному спектру приложений через «магазин» ОС, безусловно, является одним из величайших преимуществ мобильных операционных систем, но это также проблема, когда мы пытаемся использовать такие приложения для замены сделанных на заказ системы прежде всего потому, что каждое «приложение» всегда должно запускаться одинаково при первой загрузке. Однако обычно возникает необходимость персонализировать это приложение с помощью конкретных данных для телефона и / или пользователя, обычно получаемых через серверный хост.
Эта стадия персонализации проблематична, потому что очень сложно, а возможно, и невозможно аутентифицировать приложение как подлинное при самом первом запуске и подключении к серверным системам. Общие решения, как правило, используют встроенные секреты (защищенные с помощью криптографии «белого ящика») или удаленные системы «аттестации» для аутентификации экземпляра приложения.
Хранение данных в телефоне
После того, как устройство «подготовлено» и используется, подразумевается, что в этом приложении должны храниться некоторые уникальные данные. Это могут быть уникальные идентификаторы, более сложные структуры данных или уникальные криптографические ключи для конкретных приложений, которые должны быть сгенерированы и сохранены на устройстве. Существует множество вариантов безопасного хранения этих значений на мобильном устройстве, от простых разрешений на уровне файловой системы до защиты в отдельных аппаратных компонентах на устройстве.
Самый простой метод контроля доступа - использование файловой системы устройства. Здесь необходимо позаботиться о том, чтобы были применены правильные разрешения доступа, чтобы файл не был доступен для чтения, установив файл как «зависящий от приложения». Важно отметить, что даже после этого все приложения, подписанные одним и тем же ключом разработчика, выполняются от имени одного и того же пользователя и, следовательно, смогут получить доступ к любым файлам, даже если права доступа ограничены.
Начиная с Android 7 появилась возможность применять шифрование на основе файлов (FBE), которое шифрует файлы в хранилище на основе учетных данных пользователя - так что, если устройство является многопользовательским или имеет несколько профилей пользователей, доступ к приложения и файлы для этих приложений могут быть ограничены определенной учетной записью или пользователем.
Файлы, расположенные на внешнем хранилище, легко извлекаются и читаются. Более поздние версии Android позволяют «использовать» съемные носители со встроенным хранилищем и использовать шифрование для защиты этих носителей. Однако только после того, как Android 9 «адаптировал» съемные носители, работал с FBE, и по этой причине (а также по другим причинам, таким как надежность и скорость) использование внешнего хранилища для безопасных файлов, как правило, не рекомендуется.
В самом деле, обычно не считается достаточным разрешить только использование безопасности файловой системы для защиты конфиденциальной информации в приложении, и поэтому настоятельно рекомендуется использовать дополнительные механизмы защиты - чаще всего шифрование на основе приложений. Однако этот тип защиты вызывает затруднения; Хотя само шифрование может использоваться для предотвращения прямого «чтения» содержимого файла, обеспечиваемая безопасность настолько сильна, насколько надежна защита, применяемая к используемому криптографическому ключу.
К счастью, Android изначально предоставляет методы для генерации и использования ключей для шифрования файлов, так что приложениям не нужно напрямую обращаться к этим ключам или использовать их.
Хранение ключей и безопасность
Следовательно, использование шифрования для защиты данных можно рассматривать как перенос сложности защиты от файла (ов) или самих элементов данных до ключа (ов). Хорошая новость заключается в том, что, поскольку криптографические ключи намного меньше, чем большинство файлов (часто намного меньше 1 КБ), их несколько легче надежно хранить. Android предоставляет ряд конкретных методов хранения для защиты криптографических ключей, которые могут использоваться приложениями для прямого шифрования данных как для хранения, так и для транспортировки, как показано ниже.
Защита криптографических ключей в системах COTS может включать как программные, так и аппаратные методы.
Метод хранения, который вы используете, будет зависеть от желаемого уровня безопасности, сбалансированного с учетом соображений совместимости. Только программные методы, такие как криптография Whitebox или программные TEE, являются наиболее широко используемыми для множества устройств, но также обеспечивают базовый уровень безопасности по сравнению с другими вариантами. Существует множество научных статей, в которых обсуждаются атаки (и меры по их устранению) на криптографические системы Whitebox, и часто возможны такие атаки, как дифференциальные вычислительные побочные каналы и внедрение ошибок.
Аппаратные TEE и программные анклавы, которые используют аппаратные функции для разделения областей памяти (в идеале с использованием шифрования, а также других функций изоляции памяти), обеспечивают повышенный уровень разделения, гарантируя, что операции и данные, которыми управляют в этих средах, защищены от доступа систем, выполняющих в Rich Execution Environment. Однако в этих системах также возможны атаки по побочному каналу и RCE .
Из-за этих типов атак хранение криптографических ключей часто лучше всего реализовать в полностью отдельном кристалле - с использованием скрытого «чипа», такого как встроенный процессор Secure Element или Secure Enclave. Устройства с Android 9 и выше поддерживают использование такой встроенной аппаратной системы хранения данных, называемой «Strongbox», а требования утверждения Common Criteria для EAL 5+ на таких микросхемах внутренней безопасности обеспечивают очень высокий уровень гарантии безопасности. .
Конечно, прежде чем хранить ключ, вы должны иметь ключ для хранения! Создание, ввод, дешифрование или согласование ключей в мобильных системах может иметь свои собственные проблемы - некоторые стандарты (например, PCI CPoC) требуют, по крайней мере, получения исходных данных энтропии из внешних входов, таких как серверный HSM, подключенный ключ или другой пользователь. входы и датчики устройства, помогающие генерировать случайные данные.
Однако у таких датчиков могут быть свои проблемы ...
Использование данных датчиков
В предыдущем разделе мы упоминали атаки по побочным каналам, поскольку они применяются к извлечению или определению хранимых секретов, таких как криптографические ключи. Однако атаки по побочному каналу также могут применяться для восстановления данных по мере их ввода в устройство - посредством мониторинга светового датчика, акселерометра и гироскопа , даже сигнала Wi-Fi.
Мониторинг ввода ПИН-кода пользователя с помощью акселерометра
Защита от такого рода утечек во время работы затруднена без усиления защиты со стороны операционной системы для отключения использования фонового датчика. Однако важно понимать, что такие атаки возможны, чтобы вы могли встроить их в свои модели угроз по мере разработки решений.
Транспортная безопасность
Одна из самых простых вещей, которую вы можете сделать для защиты своего приложения, - это убедиться, что соединение, которое оно устанавливает с серверными системами, защищено с помощью TLS. Android делает это относительно легко, но вы должны помнить, что TLS - это набор протоколов и методов подключения, и не все из них будут обеспечивать необходимую безопасность. Если аутентичность вашего бэкэнда важна, всегда проверяйте сертификат, предоставленный этим бэкэндом (в процессе, называемом «закрепление сертификата»), чтобы убедиться, что вы не просто разговариваете с каким-либо хостом TLS - вы разговариваете с хостом, на котором вы фактически хочу поговорить!
Не менее важным, чем принятый вами сертификат, является «набор шифров», который вы используете для защиты соединения после его установления. Это выбирается на основе общих реализаций, поддерживаемых сервером и клиентским приложением (на мобильном устройстве), подчеркивая, что не только мобильное приложение влияет на безопасность любой реализации - то, как вы настраиваете любые серверные системы, также жизненно важно. .
Для реализаций с высоким уровнем безопасности вы можете рассмотреть возможность дополнительного шифрования конфиденциальных данных помимо защиты, обеспечиваемой самим TLS-соединением. Это может помочь изолировать эти данные от уязвимости в бэкэнд-системах, где соединения TLS обычно завершаются на границе сети, а также реализовать общую `` глубокую защиту '', чтобы снизить риск раскрытия, если есть проблема, вызванная раскрытием данные сертификата или обнаружена новая уязвимость в TLS.
Конфиденциальность против систем аттестации
По мере того, как мы расширяем использование систем COTS для использования в различных сферах деятельности и с различной конфиденциальной информацией, «системы аттестации» становятся все более популярными. Эти системы собирают данные с платформы и передают их в среду удаленной обработки для анализа, что позволяет сравнивать эти данные с аналогичными данными из многих других систем или проверять криптографически на основе надежно хранимого закрытого ключа.
Google реализует собственную систему аттестации, известную как SafetyNet. Это помогает предоставить информацию о базовой платформе и самом приложении в отношении того, считается ли это высоким риском. Однако Google особо отмечает, что эту систему не следует использовать в качестве единственного метода защиты или аттестации для приложения - это компонент решения, которое вам необходимо создать самостоятельно.
Safetynet также может разрешить «аттестацию ключа» обратно в сервисы Google. Это можно использовать как для проверки безопасности ключей, сгенерированных и хранимых на этом устройстве, так и для подтверждения того, что телефон является подлинным устройством Android, а не эмулятором, и имеет неповрежденную цепочку доверия для процесса загрузки. Совсем недавно Google, кажется, внедряет обновления для этого, которые могут сделать его более полезным для обнаружения «рутированных» телефонов, что хорошо для безопасности.
Что такое хорошая безопасность?
Безопасность - понятие относительное. То, что может считаться «безопасным» для одного использования, может быть небезопасным для другого варианта использования. При создании приложений для Android у Google есть хорошее руководство по вопросам, которые следует учитывать в отношении общей безопасности. Если вы создаете приложения, которые имеют более строгие требования к безопасности, чем «нормальное» приложение, вы можете также рассмотреть возможность выхода за рамки этого руководства.
- Не делайте файлы доступными для чтения
- Не используйте стандартные / общие криптографические ключи, хранящиеся в вашем приложении, для постоянной безопасности
- По возможности используйте FBE
- Используйте шифрование на основе приложений для конфиденциальных данных
- Свяжите это с ключами на основе времени и аутентификации для активов, которые требуются только временно (например, ключей, напрямую управляемых приложением)
- По возможности не управляйте ключами прямо в приложении.
- Помните, что любое другое приложение, подписанное вашими ключами разработчика, имеет тот же идентификатор пользователя.
- Используйте TLS с хорошими наборами шифров и закреплением сертификатов
- Но не привязывайте к глупым данным сертификатов!
- И не полагайтесь на TLS только в реализациях с высоким уровнем безопасности.
- Защитите свой интерфейс и учетные данные магазина приложений
- Используйте SafetyNet и аттестацию ключей как часть более сложной реализации безопасности и аттестации приложений.
- Планируйте устаревание ОС и не предполагайте наличие функций, основанных исключительно на версиях ОС.
- Ориентируйтесь на новейшие API
- Использовать программную обфускацию
Взгляды и мнения, выраженные в этой статье, не обязательно отражают официальную позицию.
