SonarQube: убедитесь, что здесь безопасно шифрование данных. AES / GCM / NoPadding, RSA / ECB / PKCS1Padding

Я использую:

1. RSA / ECB / PKCS1Padding

2. AES / GCM / NoPadding

Чтобы зашифровать мои данные в моем приложении Android (Java). В документации SonarQube говорится, что:

Алгоритм шифрования Advanced Encryption Standard (AES) может использоваться в различных режимах. Режим Галуа / счетчика (GCM) без заполнения следует предпочесть следующим незащищенным комбинациям:

  • Режим электронной кодовой книги (ECB): при заданном ключе любой заданный блок открытого текста всегда шифруется в один и тот же блок зашифрованного текста. Таким образом, он плохо скрывает шаблоны данных. В некотором смысле он не обеспечивает серьезной конфиденциальности сообщений и вообще не рекомендуется для использования в криптографических протоколах.
  • Цепочка блоков шифрования (CBC) с заполнением PKCS # 5 (или PKCS # 7) подвержена атакам оракула с заполнением.

Итак, как рекомендуется, я использую AES/GCM/NoPadding как:

Cipher c = Cipher.getInstance("AES/GCM/NoPadding");

Но он по-прежнему выдает предупреждение: Убедитесь, что здесь безопасно шифрование данных.

То же самое для:

Cipher c = Cipher.getInstance("RSA/ECB/PKCS1Padding");

Почему SonarQube выдает это предупреждение? Разве такое использование больше не безопасно?


encryption aes rsa padding aes-gcm
person Dionis Beqiraj    schedule 12.09.2019    source источник
comment
Добро пожаловать в crypto.stackexchange - похоже, это вопрос программирования, и вопросы программирования здесь не по теме, даже если программа использует криптографию. Вопросы программирования относятся к stackoverflow. Я могу перенести это туда для вас.   -  person Ella Rose    schedule 12.09.2019
comment
Что за предупреждение?   -  person President James K. Polk    schedule 12.09.2019
comment
@JamesKPolk Make sure that encrypting data is safe here.   -  person Dionis Beqiraj    schedule 13.09.2019

Ответы (2)


arrow_upward
5
arrow_downward

AES в режиме GCM защищен как алгоритм блочного шифрования. Но это не гарантирует, что код, который шифрует данные с использованием AES (в режиме GCM), защищен. Некоторые вещи могут пойти не так, что сделает код уязвимым для атак. Разработчики обязаны правильно его закодировать для достижения желаемого уровня безопасности. Вот несколько примеров, когда что-то может пойти не так:

  1. IV повторяется для данного ключа
  2. Ключ или необработанные данные хранятся в типе данных String, который продолжает оставаться в куче.
  3. Секретный ключ хранится в виде открытого текста в файле свойств, который находится в репозитории кода.

и так далее.

Теперь SonarQube не может идентифицировать все эти уязвимости, и поэтому они придумали новую концепцию под названием Hotspot, которая описывается здесь как:

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

У хотспотов есть отдельный жизненный цикл, который объясняется в приведенной выше ссылке.

P.S. В этом ответе объясняется, как зашифровать строку на Java с помощью AES в режиме GCM безопасным способом: https://stackoverflow.com/a/53015144/1235935

person Saptarshi Basu    schedule 13.09.2019

arrow_upward
1
arrow_downward

Похоже, это общее предупреждение о шифровании любых данных. Не должно быть проблем с "AES / GCM / NoPadding", так как показано в их тестовом коде.

person Swashbuckler    schedule 12.09.2019
comment
Да, но есть ли способ избавиться от этого? - person Dionis Beqiraj; 12.09.2019