SecureRandom и Crypto: реализация и использование
По умолчанию используется реализация SecureRandom, поставщик Crypto явно используется, предоставляется функция шифрования Cipher, а также функции HTTPS-коммуникации.
Влияние: без влияния.
4.2–4.3.x: используется явно указанный поставщик Crypto.
Используется явное использование поставщика Android OpenSSL, используется функция генерации случайных чисел OpenSSL, предоставляется функция шифрования Cipher, а также функция HTTPS-коммуникации.
Влияние: без влияния.
С 4.4 и далее: без влияния. Без влияния.
Начиная с августа 2013 года Google распространил среди своих партнёров (производителей оборудования и т. д.) патчи для устранения уязвимостей в операционной системе Android. Однако уязвимости, связанные с SecureRandom, затронули широкий спектр приложений, включая функции шифрования и HTTPS-коммуникаций, и многие устройства, вероятно, всё ещё не исправлены. Поэтому при разработке приложений для Android 4.3.x и более ранних версий мы рекомендуем принять во внимание стратегии реализации, обсуждаемые на сайте.
Шифрование данных: основные принципы
При использовании криптографических методов для обеспечения безопасности чувствительных данных (конфиденциальности и целостности) важно правильно обрабатывать ключи. Даже самые надёжные алгоритмы шифрования и длинные ключи не могут защитить данные от атак третьих сторон, если ключ сам по себе доступен. В связи с этим правильное управление ключами является одним из наиболее важных аспектов использования шифрования.
В зависимости от уровня защиты активов, которые вы пытаетесь защитить, правильное управление ключами может потребовать сложных проектных и реализационных решений, выходящих за рамки этого руководства. Здесь мы можем предложить только общие идеи о безопасном хранении ключей и местоположении различных активов в мобильных телефонах и планшетах Android, а также обсудить стратегии их защиты. Более подробную информацию о классификации активов и стратегиях защиты можно найти в разделе «3.1.3 Активы: классификация и стратегии защиты».
Таблица 5.6-7 содержит сводку категорий активов, подлежащих защите, и соответствующих стратегий защиты для разных владельцев активов.
Владелец актива | Пользователь устройства | Поставщик приложения / услуги | ||
---|---|---|---|---|
Уровень актива | Высокий | Средний / низкий | Высокий | Средний / низкий |
Местоположение ключа и стратегия защиты | ||||
Память пользователя | Повышение сложности пароля | Запрет использования паролей пользователей | ||
Каталог приложения (непубличное хранилище) | Шифрование или запутывание ключа | Запрещение операций чтения/записи извне приложения | Шифрование или запутывание ключа | Запрещение операций чтения/записи извне приложения |
APK-файл | Запутывание данных ключа. Примечание: большинство инструментов запутывания Java, таких как Proguard, не запутывают строковые данные. | |||
SD-карта или другое (публичное хранилище) | Шифрование или запутывание данных ключа |
Далее мы рассмотрим меры защиты для каждого места хранения ключей.
Хранение ключей в памяти пользователя
Здесь мы рассматриваем шифрование на основе паролей. При создании ключа из пароля местоположение ключа — это память пользователя, поэтому нет риска утечки из-за вредоносного программного обеспечения. Однако, в зависимости от силы пароля, ключ может быть легко восстановлен. По этой причине необходимо предпринять шаги для обеспечения надёжности пароля, аналогичные тем, что предпринимаются при вводе пароля пользователем при входе в систему, например, ограничение через пользовательский интерфейс или использование предупреждающих сообщений. См. раздел «5.6.2.6 Меры по повышению надёжности паролей (рекомендуется)». Конечно, когда пароль хранится в памяти пользователя, следует помнить о возможности его забывания. Для восстановления данных в случае забытого пароля необходимо хранить резервную копию данных вне устройства (например, на сервере).
Хранение ключей в каталоге приложения
Когда ключ хранится в частном режиме в каталоге приложения, данные ключа недоступны для других приложений. Кроме того, если приложение отключает функцию резервного копирования, пользователь также не сможет получить доступ к данным. Следовательно, при хранении ключа для защиты активов приложения рекомендуется отключить функцию резервного копирования.
Однако, если вам всё ещё нужно защитить ключ от приложений или пользователей с правами root, необходимо зашифровать или запутать ключ. Для ключей, используемых для защиты пользовательских активов, вы можете использовать шифрование на основе пароля. Для ключей, используемых для шифрования активов приложения, вы хотите, чтобы активы были невидимыми для пользователя, вы должны хранить ключ, используемый для шифрования активов, в APK-файле и запутывать данные ключа.
Хранение ключей в APK-файлах
Поскольку данные APK-файла доступны, обычно они не подходят для хранения конфиденциальных данных (таких как ключи). При хранении ключа в APK-файле необходимо запутать данные ключа и принять меры для предотвращения лёгкого доступа к данным из APK-файла.
Хранение ключей в общедоступных хранилищах (например, SD-карты)
Общедоступные хранилища, такие как SD-карты, могут быть доступны всем приложениям, поэтому обычно они не подходят для хранения конфиденциальной информации (такой как пароли). При хранении ключа в общедоступном месте необходимо зашифровать или запутать данные ключа, чтобы предотвратить лёгкий доступ к ним. Также см. раздел «Хранение ключей в каталогах приложений» выше для мер защиты, необходимых для приложений или пользователей с правами root.
Обработка ключей в процессе памяти
При использовании доступных криптографических методов в Android необходимо расшифровать (или сгенерировать ключ для основанных на паролях ключей) данные зашифрованного или запутанного ключа перед процессом шифрования до того, как они будут размещены в памяти процесса за пределами области приложения. В этом случае незашифрованные данные ключа временно находятся в памяти процесса. С другой стороны, память процесса обычно недоступна для других процессов, поэтому, если категория активов находится в пределах охвата этих руководящих принципов, особых требований к обеспечению безопасности не возникает. Если данные незашифрованного ключа неприемлемы (даже если они присутствуют в памяти процесса таким образом), возможно, потребуется запутать данные ключей и логику шифрования или использовать другие методы из-за конкретных целей или уровня активов, обрабатываемых приложением. Однако эти методы трудно реализовать на уровне Java; вместо этого вы будете использовать инструменты запутывания на уровне JNI. Эти меры выходят за рамки данного руководства; рекомендуется проконсультироваться со специалистами по безопасности проектирования и реализации.
«5.6.3.5 Решение проблем с поставщиками безопасности через сервис Google Play»
Сервис Google Play (версии 5.0 и выше) предоставляет структуру под названием «установщик поставщиков», которая может использоваться для решения проблем с безопасностью поставщиков.
Во-первых, поставщики безопасности предоставляют реализации различных алгоритмов шифрования, связанных с инфраструктурой паролей Java (JCA). Эти алгоритмы безопасности поставщиков можно использовать в приложениях Android через такие классы, как Cipher, Signature и Mac, для использования технологий шифрования в приложениях Android. Как правило, быстрое реагирование требуется всякий раз, когда обнаруживается проблема с реализацией, связанной с технологиями шифрования. Фактически, злонамеренное использование этих уязвимостей может привести к серьёзному ущербу. Поскольку технологии шифрования также связаны с поставщиками безопасности, желательно как можно скорее устранить уязвимости.
Наиболее распространённым методом исправления уязвимостей безопасности поставщиков является обновление устройства. Процесс обновления устройства начинается с подготовки обновления производителем устройства и заканчивается применением обновления пользователем на своём устройстве. Таким образом, доступность приложения для последней версии поставщика безопасности (включая последнюю версию) фактически зависит от соблюдения производителями и пользователями. Напротив, использование установщика поставщиков из сервиса Google Play гарантирует, что приложение может получить доступ к автоматически обновляемой версии поставщика безопасности.
Используя установщик поставщиков из сервиса Google Play, приложение может получать доступ к поставщикам безопасности, предоставляемым сервисом Google Play. Сервис Google Play автоматически обновляет поставщиков безопасности через магазин Google Play, поэтому поставщик безопасности автоматически обновляется до последней версии без необходимости соблюдения производителями или пользователями.
Пример кода для вызова установщика поставщиков выглядит следующим образом.
Вызов установщика поставщиков
import com.google.android.gms.common.GooglePlayServicesUtil;
import com.google.android.gms.security.ProviderInstaller;
public class MainActivity extends Activity
implements ProviderInstaller.ProviderInstallListener {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
ProviderInstaller.installIfNeededAsync(this, this);
setContentView(R.layout.activity_main);
}
@Override
public void onProviderInstalled() {
// Called when Security Provider is the latest version, or when installation completes
}
@Override
public void onProviderInstallFailed(int errorCode, Intent recoveryIntent) {
GoogleApiAvailability.getInstance().showErrorNotification(this, errorCode);
}
}
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )