我希望我的Android/iOS应用和我的可通过互联网访问的后端服务之间进行安全通信，因此我正在研究HTTPS/SSL。
如果我创建自签名证书，然后将客户端证书放入应用程序中并要求后端服务需要该客户端证书，这样真的安全吗？
这就是我为什么问的原因。看起来客户端证书可能会被通过检查.apk文件而“破解”。客户端证书只是一个字符串常量，是吗？这意味着任何人都可以使用客户端证书来访问我的后端。 .apk文件（和iOS的等效文件）是否足够不透明，以防止发现客户端证书？
移动应用中的客户端SSL证书有多安全？
28
- Jacob Marble
3
“只使用一个普通的、可信的证书”是什么意思？这不就是你正在做的吗？ - user207421
我修改了问题。请告诉我是否更清晰明了。 - Jacob Marble
不要忘记我们有一个专门解答这类问题的网站...[security.se]。如果有人觉得需要标记，这里也是可以讨论的主题。 - user1228
5个回答
15
你是否正在使用SSL进行客户端证书身份验证？尽管对于这个问题并不重要。但是，你在应用中存储的所有私钥都可以被攻击者访问。每个客户端都应该有自己的证书和密钥对，以防止大规模泄漏。你的服务器还应强制执行保护措施，确保受损客户端不能随意请求任何内容。
对于任何身份验证方案来说都是如此。如果你嵌入了密码、API密钥、解密密钥等信息。设备上的任何内容都应该被认为是可访问的。
证书提供的额外安全性部分源于没有什么可以被暴力破解。如果你为每个客户端选择用户名/密码路线，密码可能会被猜测。API密钥也是一样（虽然它们更长且更难）。采用证书，就是完全不同类别的攻击，而且是一个相当棘手的问题。
但最重要的是，后端服务不应允许应用程序执行其本来不会执行的任何操作。
现在，处理证书，你将面临许多其他问题。你可能希望用你的自签名CA证书为每个客户端证书签名。根据你的使用情况，管理该CA证书可能存在问题。你将生成这些客户端证书吗？还是由你通过手动方式生成？也就是说，这是可以供百万人下载的应用，需要一个自动生成它们的自动化系统吗？还是这是你个人将处理生成证书的私有/内部应用程序？
对于任何身份验证方案来说都是如此。如果你嵌入了密码、API密钥、解密密钥等信息。设备上的任何内容都应该被认为是可访问的。
证书提供的额外安全性部分源于没有什么可以被暴力破解。如果你为每个客户端选择用户名/密码路线，密码可能会被猜测。API密钥也是一样（虽然它们更长且更难）。采用证书，就是完全不同类别的攻击，而且是一个相当棘手的问题。
但最重要的是，后端服务不应允许应用程序执行其本来不会执行的任何操作。
现在，处理证书，你将面临许多其他问题。你可能希望用你的自签名CA证书为每个客户端证书签名。根据你的使用情况，管理该CA证书可能存在问题。你将生成这些客户端证书吗？还是由你通过手动方式生成？也就是说，这是可以供百万人下载的应用，需要一个自动生成它们的自动化系统吗？还是这是你个人将处理生成证书的私有/内部应用程序？
- mfanto
13
证书是无害的。需要保护的是私钥，而且只有设备本身安全，才能确保私钥的安全性。将证书和私钥与应用程序一同发布，这意味着任何拥有该应用程序的人都可以获得密钥，因此这并不提供任何安全保障。我认为您需要一些后安装的注册步骤。
- user207421
2
“任何拥有该应用程序的人都拥有密钥，因此它不会为您提供任何安全性……” - 这是真正的问题。这被称为“无人值守密钥存储”问题。这是一个非常棘手的问题。还可以参考Gutmann的《工程安全》一书。 - jww
13
通常，客户端SSL证书存储在密钥库中（在Android的情况下为BKS格式），并将密钥库作为资源包含在您的APK中。密钥库是加密和受密码保护的。因此，客户端证书无法从APK中轻松提取，因为它以加密形式存储。
现在...密码怎么办？这是问题的关键，你有两个选择。
如果您希望应用程序能够在没有用户交互的情况下与服务器通信（因此能够访问证书），则需要将密码嵌入应用程序中，然后，是的，攻击者可以反向工程化您的代码来查找它，抓取密钥库，然后解密它以恢复证书。您可以应用技术，如混淆代码，使攻击者更难以这样做，但这只会减慢某些人的速度，而不会防止它。
您的另一个选择是每次应用程序与服务器通信时提示用户输入密码，并使用该密码解密密钥库（或在应用程序启动时询问并缓存证书一段时间）。这里的优点是，如果有人反向工程化您的APK，则会找到经过加密的密钥库，而没有密码，因此您的证书是安全的。缺点是要求用户提供密码。
现在...密码怎么办？这是问题的关键，你有两个选择。
如果您希望应用程序能够在没有用户交互的情况下与服务器通信（因此能够访问证书），则需要将密码嵌入应用程序中，然后，是的，攻击者可以反向工程化您的代码来查找它，抓取密钥库，然后解密它以恢复证书。您可以应用技术，如混淆代码，使攻击者更难以这样做，但这只会减慢某些人的速度，而不会防止它。
您的另一个选择是每次应用程序与服务器通信时提示用户输入密码，并使用该密码解密密钥库（或在应用程序启动时询问并缓存证书一段时间）。这里的优点是，如果有人反向工程化您的APK，则会找到经过加密的密钥库，而没有密码，因此您的证书是安全的。缺点是要求用户提供密码。
哪种方法最好？这完全取决于您所关心的数据的敏感性和您愿意接受的风险水平。只有您才能回答这个问题。
- user121356
2
7注意：如果用户是攻击者，提示输入密码并不能解决问题。 - Eugene Mayevski 'Callback
私钥是加密的，证书不是。除非私钥也泄漏，否则泄漏证书没有风险。 - user207421
4
Daniel Guillamot，一些我所掌握的技巧：
- 拆分服务器端密钥。将SSL密钥的密码短语设置为应用程序字符串XOR从网络服务中获取的字符串的结果。
- 通过调用一些应用程序函数来创建应用程序字符串，而不是硬编码字符串。
- 禁止在应用程序运行时跟踪应用程序，以避免某人在调用私钥解密时捕获最终密码短语。参考：http://books.google.no/books?id=2D50GNA1ULsC&lpg=PA294&ots=YPQQ7DLjBD&dq=The%20example%20just%20shown%20demonstrates%20how%20calls%20to%20ptrace%20can%20be%20hijacked&hl=no&pg=PA293#v=onepage&q&f=false
如果有其他想法，我很乐意听取。
- janfrode
1
丹尼尔的回答并不是真正的答案，更像是一条评论，你的回答在某种程度上也是如此... - Bruno
1
APK 可以被访问和复制，所以将任何东西放入其中都没有作用。在安装后进行激活，可能需要将证书绑定到设备上。例如，可以通过将设备的 IMEI 放入证书扩展之一，并通过应用程序传递 IMEI 和证书来进行绑定（或者更好地，在身份验证和建立安全通道后传递 IMEI）。
- Eugene Mayevski 'Callback
1
IMEI不是安全的：它可能被克隆。 - 0zkr PM
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接