为什么要保护API
Stewart最初是在美国国家半导体（National Semiconductor）担任芯片设计师，他并不是说硬件安全没有必要，他完全了解基于硬件安全的重要性和能力。但CriticalBlue的过去的项目，包括开发软件优化工具来改善移动硬件性能，已使Stewart和他的团队对软件在移动平台上的作用有了深刻了解。
CriticalBlue目前专注于保护API，以保护基于手机app的产品和服务。
在本周发布的一份白皮书中，CriticalBlue写道：
对于为手机app提供服务的API而言，问题在于，任何人（包括攻击者）都可以在他/她控制的设备上自由安装app，从而对其进行逆向工程并研究其弱点。
CriticalBlue列出了API面临的五大威胁，从中间人攻击和数据抓取到凭证填充，app模拟和拒绝服务攻击。
值得注意的是，服务供应商使用的app依赖于来自不同供应商的多个API提供的数据和服务。一个典型的app同时使用内部和第三方API，每个API都有自己的访问管理和相关收费方法。在允许访问之前，大多数API要求app在每次请求时都提供有效的API密钥。
当黑客通过对app进行逆向工程来提取API密钥时，问题就出现了。
CriticalBlue解释说，由于API是开放的并在app中发布，因此API密钥有很多方式可以落入错误的人手中。
例如，黑客可以发起中间人攻击（通过拦截API流量）来窃取密钥。然后，他们可以通过数据抓取或虚假账户创建的自动脚本发起重播攻击。
毫无疑问，后果是可怕的。攻击者可能会控制计费API，以获取客户付款。竞争对手也可能会抓取专有数据，例如价格信息。根据CriticalBlue的说法，假冒app可能使网络罪犯创建“仿制的、受恶意软件感染的app版本，并诱骗潜在的客户下载它”。更糟糕的是，模拟威胁可能“使攻击者对你的API协议进行逆向工程，并构建新软件来假冒真实应用进行任意API调用，或者以其他方式访问你的后端基础架构，与服务器通信并从中获取信息。”
Stewart指出：“例如，当服务供应商需要验证与API通信的代理是你在安全环境中运行的可靠应用时，CriticalBlue的Approov就会出现。”Approov可以通过远程识别“app独特的DNA和安全的运行时间环境来做到这一点。Approov在app中不使用API密钥。相反，Approov为API调用提供了短期的令牌。
正如Stewart解释的那样，此处的目标是“确保不将密钥传递给修改后的app或不被信任的移动环境中运行的app。”
CriticalBlue的Approov是一种实时产品，现已由德国汽车租赁公司Sixt部署，以解决API滥用问题。这家租赁公司为Sixt Share选择了Approov，Sixt Share是最初与宝马合作建立的汽车共享公司。
为什么不追求标准？
提到恩智浦基于硬件的CCC数字钥匙标准2.0的安全解决方案时，Stewart承认：“由于恩智浦硬件安全实施了该标准，这意味着每台移动设备与每辆车之间都可以轻松互操作。标准是一件很棒的事。”
但他指出，标准也有不利之处。“市场需要很长时间才能升级硬件以使用新技术。”Stewart问道：“那么，现实地说，CCC数字钥匙标准2.0需要多久才能被所有正在使用的汽车和手机所支持？”
CCC还在开发支持蓝牙低功耗（BLE）的3.0版本。Stewart说：“Approov已在我们的离线模式中使用了BLE，但其他安全解决方案以及手机和车辆之间的通信app也正在使用BLE。因此，你会再次看到标准滞后于业务需求。”
最后，Stewart指出，即使使用非常强大的硬件，糟糕的实施也可能会危及安全。“重要的是，这种安全性要易于实施和部署。”
实际上，CriticalBlue的Approov是一款目前就可以订阅的服务，而Approov SDK可以自动管理云端的完整性检查。
但如果Approov像Stewart所说的那样有效，那么CriticalBlue为什么不加入CCC？API安全不应该成为行业标准的一部分吗？
Stewart说：“我们当然有考虑过，但对于像我们这样的小公司来说，这似乎是一项太过长期的计划，无法投入时间。此外，标准组织通常希望创建一种能够满足所有参与者要求的折衷解决方案。除非我们开源或免费，否则他们不会采用Approov这样的专有解决方案。”
他总结说，对于像CriticalBlue这样的小公司来说，顺应行业联盟的步调并不是一种理想的生存策略，“小公司正试图努力把事情做好，并尽可能获得市场份额。”
[参考文章]
If car keys are apps, API security is key — Junko Yoshida
from A to B
