如今，智能手机上的应用程序已成为所有数字商务之母，企业正狂热地推出基于应用程序的产品和服务——例如，数字汽车钥匙应用程序和汽车共享服务——这些产品和服务向消费者承诺以最小的麻烦获得最佳的便利。美中不足的就是安全问题。

目前解决基于应用程序的数字车钥匙漏洞的一个方法是投入更多的硬件来解决这个问题。NXP半导体等技术供应商正在提供汽车原始设备制造商认可的安全元件和NFC芯片组，并计划通过增加蓝牙低能耗(BLE)和超宽带(UWB)，在数字汽车密钥中增加一层额外的安全保护。NXP是汽车连接联盟(CCC)的成员，这是一个跨行业组织。CCC正带头推动汽车行业将“智能手机到汽车连接”的解决方案标准化。

CriticalBlue的首席执行官David Stewart最近在表示，在将所有利益相关者(包括汽车原始设备制造商、智能手机公司和技术供应商)聚集在一起，同意添加一套特定的硬件安全芯片之前，需要先考虑一下。例如，要用一款可以打开汽车的应用程序来设计一项服务，“了解你的应用程序的功能”是至关重要的。“更重要的是，你应该知道你的应用程序在与什么通信。”

Stewart解释：保护数字汽车钥匙应用程序的首要任务是保护API，因为每个移动应用程序都是由移动应用程序中发布的API所驱动。

Stewart:“硬件安全对于确保密钥的安全非常重要，但现实情况是，移动应用程序是用来获取和处理(密钥)的。他指出，薄弱环节正是“数字密钥被传递到移动应用程序”这一过程。

CriticalBlue提供一个名为Approov的产品，该产品由其自己的后端基础结构支持，用于验证用户、验证通道和验证应用程序。

API这个词，全称叫Application Programming Interfaces（应用程序编程接口）。简单地说，就是一套套的要求，用来管理应用程序之间的沟通。API并不是什么新事物，在你使用PC或笔记本时，正是API让数据在程序之间传输。例如，把一个LibreOffice文档中的片断切割出来并传输到Excel表格上。系统级的API让LibreOffice这类程序能够运行在Windows这样的操作系统上。

在互联网中，API让其它应用可以使用一些大的服务，如Google Maps和Facebook。例如Yelp，它可以在Google Map上显示附近的餐馆；还有一些游戏可让用户通过Facebook与其它玩家聊天、分享得分等。

API是通过把程序内部的一些功能有限地向外开放来做到的，这使得应用之间可基于各自的利益分享数据，同时不需要开发者公布所有的软件代码。对开源项目来说也是如此。你可以把它看成是一扇门、窗或杠杆，不管用什么比喻，一个程序和外面的软件世界的沟通就是由API定义的。

API如何运作？

目前API变得十分重要，因为它们决定了开发者如何把自己新开发的应用接入大型的网络服务。例如一款游戏应用的开发者，他可以使用Dropbox的API让用户把游戏数据存储在Dropbox的云里，而不用费力去开发自己的云存储服务。

API还能节省时间，例如国外使用Facebook账号，国内使用QQ账号，都可以直接登录很多的应用和网站，免去了注册环节，这也是通过API实现的。

从一个更广泛的角度来看，API使各种“混搭”的网络服务成为了可能，开发者通过混搭来自Google、Facebook或Twitter的API来创造全新的应用和服务。在许多方面，可以说是主流服务API的广泛应用才使现代网络体验成为可能。

以Yelp的Android应用为例，当你搜索附近的餐馆时，位置信息会出现在Google地图上，Yelp没有开发自己的地图。通过Google地图的API，Yelp应用把自家的信息——餐饮地址、用户评价等——发送到内部的Google地图功能，最后得到一幅带有周围餐馆位置的地图展示给用户，这些都显示在Yelp应用内部。

为什么要保护api?

Stewart的职业生涯始于美国国家半导体公司(National Semiconductor)的芯片设计师，他并不是说硬件安全没有必要。反而他充分认识到硬件安全的重要性和能力。但是CriticalBlue过去的项目，包括开发软件优化工具来提高移动硬件性能，已经让Stewart和他的团队深入了解了软件在移动平台上扮演的角色。

当API出现问题

一个API现在可用，并不意味着将来也可用。以Twitter为例，一年以前就以限制第三方应用使用其API而臭名昭著，这种做法杀死了所有的第三方Twitter客户端，让用户只能使用Twitter自家的网站和应用，Twitter从中展示广告赚钱。Twitter称自己坚持这么做是为了保持统一的Twitter用户体验。

有些公司可能会关闭服务和API，例如Google就总是把一些见不到利润的服务关闭，最近的例子是Google Reader，如果你的应用依赖这些API来运行的话，就会随之一同出现问题。

虽然API的世界并不完美，但依然阻止不了开发者对其的热情，也阻止不了由其促成的各种多样化应用和服务。

今天，CriticalBlue专注于保护api得工作，这是为了以后保护基于移动应用程序的产品和服务。

在最近的一份白皮书中，CriticalBlue写道:

当涉及到服务于移动应用程序的api时，问题是任何人(包括攻击者)都可以在他/她控制的设备上自由地安装应用程序，从而对其进行逆向工程并研究其弱点。

CriticalBlue列出了api面临的五大威胁，从中间人攻击和数据抓取到凭证填充、应用程序模拟和拒绝服务攻击。

值得注意的是，服务提供商使用的应用程序依赖于来自不同供应商的多个api提供的数据和服务。一个典型的应用程序同时使用内部和第三方api——每个api都有自己的访问管理和相关收费方法。在允许访问之前，大多数API要求应用程序为每个请求提供一个有效的API密钥。

Approov为您的应用程序提供安全通道

例如，当服务提供商需要“验证与您的API通信代理是您是否在安全环境中运行的真实应用程序时，CriticalBlue的Approov将会出现，”Stewart指出，Approov可以通过远程识别“应用程序独特的DNA和安全的运行时环境”来做到这一点。Approov在应用程序中不使用API密钥。相反，Approov为API调用提供了短期的令牌。

正如Stewart所解释，Approov的目标是“确保密钥不会被传递到修改过的应用程序或在不可信的移动环境中运行的应用程序。”

CriticalBlue的Approov是一个实时产品，现在由德国汽车租赁公司Sixt部署，以解决API滥用问题。这家租赁公司选择了Approov，并获得了SixtShare的股份。SixtShare是该公司最初与宝马(BMW)合作创办的一家汽车共享公司。

Approov是如何工作的，如何部署它？

为什么不追求标准呢?

当被问及NXP基于硬件的CCC数字密钥标准2.0安全解决方案时。Stewart承认，“由于NXP硬件安全实现了这个标准，这意味着每个移动设备和每个车辆之间都可以轻松地实现互操作性。谁都想统一标准。”

但他指出，标准也有负面影响。“市场需要很长时间来升级硬件，以使用新技术。Stewart问道，“那么，现实地说，CCC数字密钥标准2.0需要多长时间才能被所有正在积极使用的汽车和手机所支持?”

CCC还在开发支持蓝牙低能耗(BLE)的3.0版本。Stewart:“Approov已经在我们的离线模式中使用了BLE，但其他的安全解决方案和移动设备与车辆之间的通信应用也在使用BLE。因此，你会再次看到标准滞后于当今业务需求的挑战。”

最后，即使是非常强大的硬件，糟糕的实现也会危及安全性，Stewart指出：“重要的是，这种安全措施易于实施和部署。”

实际上，公司可以订阅CriticalBlue的Approov服务，让ApproovSDK自动管理云中的完整性检查。

但如果Approov像Stewart所说的那样有效，那么CriticalBlue为什么不加入CCC？API安全不应该成为行业标准的一部分吗？

Stewart说：“我们当然有考虑过，但对于像我们这样的小公司来说，这似乎是一项太过长期的计划，无法投入时间。此外，标准组织通常希望创建一种能够满足所有参与者要求的折衷解决方案。除非我们开源或免费，否则他们不会采用Approov这样的专有解决方案。”

他总结说，对于像CriticalBlue这样的小公司来说，顺应行业联盟的步调并不是一种理想的生存策略，“小公司正试图努力把事情做好，并尽可能获得市场份额。”

延伸阅读——通过API漏洞控制Nissan Leaf电动汽车

作为日本知名汽车厂商旗下的电动车系列，日产LEAF采用非安全API帮助用户查询并控制其各项车载功能——然而该API并不具备验证设定，意味着任何人都能够通过互联网连接与其加以访问。

日产LEAF这一缩写源自“领先的环保型经济家用轿车（Leading Environmentally- friendly Affordable Family car）”，同时也是目前日产旗下最受欢迎的电动车型之一。LEAF汽车提供一款可选移动应用，允许车主对其受限功能集进行确认及控制。

来自不同国家的用户发现多个未受保护的API

过去几个月以来，互不相关的用户们各自独立发现了日产LEAF所使用的API端点。用户移动应用可借此发送各类命令，然而日产及其负责服务器管理的合作伙伴却并未对这些命令加以保护。

安全专家Troy Hunt近日发现Leaf配套应用程序NissanConnect存在系统BUG，允许其他任何人访问驾驶员的行车历史轨迹并扰乱车辆的供暖和空调系统，而且在攻击过程中黑客并不需要靠近车辆，只需要知道位于车辆前挡风玻璃的车辆识别号（简称VIN）就能发起攻击。

多位用户发现自己能够查看LEAF车辆的电池状态、命令其开始或者停止充电、开启/关闭空调系统甚至检索与之前行程相关的信息。

上述各项请求只需通过几项设定即可实现，攻击者可以猜测或者通过互联网获取设定方法——甚至包括本应属于私有信息的VIN。

不过日产公司还是做了件好事，即不允许通过API启动/停止车辆，或者开启/锁定车门。除此之外，该API亦不会泄露车主的个人身份信息——而仅仅提供部分车辆设定数据。

日产公司已经意识到这一问题，但目前尚未做出任何针对性声明。

第一位发现上述问题的用户来自某加拿大汽车论坛。该问题随后又被一位挪威安全研究员发现，并报告给了Have I BeenPwned？网站持有者Troy Hunt——当时他正在国内参加安全会议。

在确认该API确实缺少用户身份验证机制后，Hunt先生于今年1月23日同日产方面取得联系，并向后者报告了相关问题。

截至本文发稿之时，日产LEAF API仍然直接暴露于互联网之下，不过Hunt先生表示用户可以通过对应的门户网站关闭车辆的远程管理功能。该门户网站的具体URL取决于用户所在国家及地区。