5.6.2 Правила

При использовании шифрования необходимо соблюдать следующие правила:

5.6.2.1 При указании алгоритма шифрования обязательно явно указывать режим шифрования и заполнение

При использовании технологий шифрования, таких как шифрование данных и проверка подлинности, необходимо явно указать режим шифрования и заполнение. В Android при разработке приложений для шифрования обычно используется класс Cipher из пакета java.crypto. Для использования класса Cipher сначала необходимо указать тип используемого шифрования. Это называется преобразованием, и оно может быть выполнено двумя способами:

• алгоритм/режим/заполнение;
• только алгоритм.

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

5.6.2.2 Необходимо использовать сильные алгоритмы (особенно соответствующие стандартам) (обязательно)

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

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

Стандарты шифрования различаются в зависимости от страны. Подробнее см. в таблице ниже (единицы измерения — биты).

Таблица 5.6-1 NIST (США) NIST SP800-57 | Алгоритм | Жизненный цикл | Симметричное шифрование | Асимметричное шифрование | Шифрование эллиптических кривых | HASH (цифровая подпись) | HASH (генерация случайных чисел) | | --- | --- | --- | --- | --- | --- | | ~2010 | 80 | 1024 | 160 | 160 | 160 | | 2030 | 112 | 2048 | 224 | 224 | 160 | | 2030 | 128 | 3072 | 256 | 256 | 160 |

Таблица 5.6-2 ECRYPT II (ЕС)

Таблица 5.6-3 CRYPTREC (Япония) CRYPTREC Список алгоритмов шифрования

5.6.2.3 При использовании шифрования на основе пароля не следует хранить пароль на устройстве (обязательно)

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

5.66.2.4 При генерации ключа из пароля всегда используйте соль (обязательно)

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

Пример:

public final byte[] encrypt(final byte[] plain, final char[] password) {
    byte[] encrypted = null;
    try {
        // *** POINT *** Explicitly specify the encryption mode and the padding.
        // *** POINT *** Use strong encryption methods (specifically, technologies that meet the relevant criteria), including algorithms, block cipher modes, and padding modes.
        Cipher cipher = Cipher.getInstance(TRANSFORMATION);
        // *** POINT *** When generating keys from passwords, use Salt.
        SecretKey secretKey = generateKey(password, mSalt);

5.6.2.5 При генерации ключа из пароля укажите соответствующее количество итераций хеширования (обязательно)

При генерации ключа шифрования на основе пароля необходимо выбрать количество повторений процесса хеширования («растяжение») во время генерации ключа. Важно выбрать достаточно большое число, чтобы обеспечить высокий уровень безопасности. Обычно 1 000 или больше повторений достаточно. Если ключ используется для защиты более ценных активов, рекомендуется выбрать 1 000 000 повторений или более. Поскольку процесс хеширования требует незначительных вычислительных ресурсов, злоумышленники могут легко провести атаку методом перебора. Таким образом, используя метод растяжения, который включает многократное повторение процесса хеширования, мы можем намеренно увеличить время, затрачиваемое на процесс, делая атаку методом перебора более дорогостоящей. Обратите внимание, что количество итераций также влияет на скорость обработки приложения, поэтому рекомендуется тщательно выбирать подходящее значение.

Пример:

private static final SecretKey generateKey(final char[] password, final byte[] salt) {
    SecretKey secretKey = null;
    PBEKeySpec keySpec = null;

    (Omit)

    // *** POINT *** When generating a key from password, use Salt.
    // *** POINT *** When generating a key from password, specify an appropriate hash iteration count.
    // *** POINT *** Use a key of length sufficient to guarantee the strength of encryption. 
    keySpec = new PBEKeySpec(password, salt, KEY_GEN_ITERATION_COUNT, KEY_LENGTH_BITS);

5.6.2.6 Принимайте меры для повышения сложности пароля (рекомендуется)

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