encryption - SonarQube : Make sure that encrypting data is safe here. AES/GCM/NoPadding、RSA/ECB/PKCS1Padding

Question

我正在使用:

1. RSA/ECB/PKCS1填充

2. AES/GCM/NoPadding

在我的 Android (Java) 应用程序中加密我的数据。在 documentation SonarQube 指出:

高级加密标准 (AES) 加密算法可用于各种模式。没有填充的伽罗瓦/计数器模式 (GCM) 应该优先于以下不安全的组合:

电子密码本(ECB)模式:在给定 key 下，任何给定的
明文 block 总是被加密为相同的密文 block 。
因此，它不能很好地隐藏数据模式。从某种意义上说并不
提供严重的消息 secret 性，不推荐
完全用于加密协议(protocol)。

具有 PKCS#5 填充(或 PKCS#7)的密码 block 链接 (CBC) 是
容易受到填充预言机攻击。

所以，因为它是 推荐 , 我用 AES/GCM/NoPadding作为 :

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

但是，它仍然给我警告确保在此处加密数据是安全的。

相同的:

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

为什么 SonarQube 抛出那个警告？
这些用途不再安全了吗？

Answer 1

GCM 模式下的 AES 作为分组密码算法进行保护。但这并不能保证使用 AES(在 GCM 模式下)加密数据的代码是安全的。有几件事可能会出错，使代码容易受到攻击。以正确的方式对其进行编码以获得所需的安全级别是开发人员的责任。一些可能出错的例子是:

IV 对给定键重复

key 或原始数据存储在 String一直在堆中徘徊的数据类型

key 以明文形式存储在代码存储库中的属性文件中

等等。

现在，SonarQube 无法识别所有这些漏洞，因此他们提出了一个名为 Hotspot 的新概念，描述为 here。作为:

Unlike Vulnerabilities, Security Hotspots aren't necessarily issues that are open to attack. Instead, Security Hotspots highlight security-sensitive pieces of code that need to be manually reviewed. Upon review, you'll either find a Vulnerability that needs to be fixed or that there is no threat.

热点有一个单独的生命周期，在上面给出的链接中进行了解释。

附言此答案解释了如何以安全的方式在 GCM 模式下使用 AES 加密 Java 中的字符串:https://stackoverflow.com/a/53015144/1235935